Re: Version of Jakarta-ORO (Re: Tonight's Nightly Build Dependencies)

2004-07-08 Thread Martin Cooper

On Thu, 8 Jul 2004, Joe Germuska wrote:
At 12:41 AM -0700 7/6/04, Craig McClanahan wrote:
I've updated my nightly build script (effective with the 20040706 build) 
to use the following dependnet libraries, which I'm assuming corresponds 
to what we'll actually use in a Struts 1.2.1 release. Can whoever is going 
to be release manager for this confirm the version numbers?

jakarta-oro 2.0.7
I just happened to be looking this over to check the versions in the Struts 
1.2.1 distribution and I noticed that we're using Oro 2.0.7 but the current 
release is 2.0.8.

Is our general plan always to use the newest release of all libraries?  If 
so, we should update the Oro dependency.  Small, I'm sure, but still...
I think it would be good to update to ORO 2.0.8, since there are a couple 
of fixes to regexp matching in there. See:

http://cvs.apache.org/viewcvs/~checkout~/jakarta-oro/CHANGES?content-type=text/plain
Of course, it's also easy for people to upgrade it themselves if they 
encounter the problems, so it's not that big of a deal.

--
Martin Cooper

Joe
--
Joe Germuska[EMAIL PROTECTED]  http://blog.germuska.comIn 
fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know 
I'm in the wrong place.
  - Carlos Santana

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Version of Jakarta-ORO (Re: Tonight's Nightly Build Dependencies)

2004-07-08 Thread Craig McClanahan
Joe Germuska wrote:
At 12:41 AM -0700 7/6/04, Craig McClanahan wrote:
I've updated my nightly build script (effective with the 20040706 
build) to use the following dependnet libraries, which I'm assuming 
corresponds to what we'll actually use in a Struts 1.2.1 release. Can 
whoever is going to be release manager for this confirm the version 
numbers?

jakarta-oro 2.0.7

I just happened to be looking this over to check the versions in the 
Struts 1.2.1 distribution and I noticed that we're using Oro 2.0.7 but 
the current release is 2.0.8.

Is our general plan always to use the newest release of all 
libraries?  If so, we should update the Oro dependency.  Small, I'm 
sure, but still...

Joe
Has anyone tested with 2.0.8?  If so, I don't have any problem with 
picking this up in a subsequent 1.2.x release.  I'll update the nightly 
build dependencies for tonight's run.

Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Version of Jakarta-ORO (Re: Tonight's Nightly Build Dependencies)

2004-07-08 Thread Ted Husted
On Thu, 08 Jul 2004 09:36:42 -0700, Craig McClanahan wrote:
 Has anyone tested with 2.0.8?  If so, I don't have any problem with
 picking this up in a subsequent 1.2.x release.  I'll update the
 nightly build dependencies for tonight's run.

I did consider changing the dependency, but decided against an 11th hour change.

If people think it's a worthwhile change, we can roll Struts 1.2.2 after we see if 
there is feedback on other issues.

-Ted.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Version of Jakarta-ORO (Re: Tonight's Nightly Build Dependencies)

2004-07-08 Thread Joe Germuska
Has anyone tested with 2.0.8?  If so, I don't have any problem with 
picking this up in a subsequent 1.2.x release.  I'll update the 
nightly build dependencies for tonight's run.
I've been running a Struts 1.2.x app against ORO 2.0.8 for several 
months using at least email validation and having no problems. 
Martin is right that it's trivial for users to upgrade.  I think we 
should update nightlies and not worry about it for Struts 1.2.1 and 
not bother with a Struts 1.2.2 if it's just to roll that in.

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn 
back; I'll know I'm in the wrong place.
   - Carlos Santana

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Tonight's Nightly Build Dependencies

2004-07-06 Thread Nicolas De Loof

Can't we use timestamp versions for validator ?

It is used by some maven plugins that are build using SNAPSHOT dependecies. When a 
release is done, the snapshot is
converted to a timestamp. Using this, no 'official' version of the dependency is 
needed (it only needs to be deployed on
ibiblio). Timestamp can be used to get dependecies sources from CVS if needed.

Using this, a 1.2.1 version of struts may be tagged. If any bug is discovered in 
validator using this *beta* Struts
version, it will help getting an official validator-1.1.3, and then a *stable* 1.2.x 
version of Struts.

Nico.

 Comment below

 Craig McClanahan wrote:

  I've updated my nightly build script (effective with the 20040706
  build) to use the following dependnet libraries, which I'm assuming
  corresponds to what we'll actually use in a Struts 1.2.1 release.  Can
  whoever is going to be release manager for this confirm the version
  numbers?
 
  antlr.jar 2.7.2 (*)
  commons-beanutils 1.6.1
  commons-collections 3.1
  commons-digester 1.5
  commons-fileupload 1.0
  commons-logging 1.0.4
  commons-validator 1.1.3 (**)
  jakarta-oro 2.0.7
 
  [SNIP]
 
  ** I'm temporarily using the version from Ted's public_html directory,
but I'm -1 on a Struts 1.2.1 release until this is voted to be a
  validator
release suitable for public use.

 This is a Chicken and an an Egg situation. Not enough people use
 Validator standalone for it to be promoted. Validator 1.1.3 only works
 with a nightly build of Struts. So to get the required number of users
 Validator will need in a released version of Struts to get the testing
 it needs to be promoted.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



Our name has changed.  Please update your address book to the following format: 
[EMAIL PROTECTED].

This message contains information that may be privileged or confidential and is the 
property of the Capgemini Group. It is intended only for the person to whom it is 
addressed. If you are not the intended recipient,  you are not authorized to read, 
print, retain, copy, disseminate,  distribute, or use this message or any part 
thereof. If you receive this  message in error, please notify the sender immediately 
and delete all  copies of this message.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tonight's Nightly Build Dependencies

2004-07-06 Thread Joe Germuska
This is a Chicken and an an Egg situation. Not enough people use 
Validator standalone for it to be promoted. Validator 1.1.3 only 
works with a nightly build of Struts. So to get the required number 
of users Validator will need in a released version of Struts to get 
the testing it needs to be promoted.
Isn't this one of the benefits of the new release scheme that both 
projects use?. I would be -1 on voting to call Struts 1.2.1 General 
Availability if we couldn't call Validator 1.1.3 General 
Availability -- but that isn't the same as being -1 on *releasing* 
Struts 1.2.1

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn 
back; I'll know I'm in the wrong place.
   - Carlos Santana

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Tonight's Nightly Build Dependencies

2004-07-06 Thread Ted Husted
The idea is that we are doing them in tandem. We rolled Validator 1.1.3, so now can 
roll Struts 1.2.1. Once a nounrelease/noun is rolled, then we decide whether to 
verbrelease/verb it as beta or stable/General Availability. The votes are not 
final, so we can vote them to beta and then to stable after community review and 
testing.

The advantage of the current system is that we can change the status of a release 
without rolling it again. So, if Validator 1.1.3 goes stable, then Struts 1.2.1 could 
follow suit, and we would not have to touch the distribution.

-Ted.

On Tue, 06 Jul 2004 08:00:44 -0500, Joe Germuska wrote:
 This is a Chicken and an an Egg situation. Not enough people use
 Validator standalone for it to be promoted. Validator 1.1.3 only
 works with a nightly build of Struts. So to get the required
 number of users Validator will need in a released version of
 Struts to get the testing it needs to be promoted.


 Isn't this one of the benefits of the new release scheme that both
 projects use?. I would be -1 on voting to call Struts 1.2.1
 General Availability if we couldn't call Validator 1.1.3 General
 Availability -- but that isn't the same as being -1 on *releasing*
 Struts 1.2.1

 Joe



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tonight's Nightly Build Dependencies

2004-07-06 Thread Ted Husted
On Tue, 06 Jul 2004 00:41:13 -0700, Craig McClanahan wrote:
 Can whoever is going to be release manager for this confirm the version numbers?

Did you want to go ahead and do it, Craig?

There are other things I really should be doing right now, but no one else was 
available.

Of course, if you are still recovering, I can finish up.

-Ted.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tonight's Nightly Build Dependencies

2004-07-06 Thread Craig McClanahan
Joe Germuska wrote:
This is a Chicken and an an Egg situation. Not enough people use 
Validator standalone for it to be promoted. Validator 1.1.3 only 
works with a nightly build of Struts. So to get the required number 
of users Validator will need in a released version of Struts to get 
the testing it needs to be promoted.

Isn't this one of the benefits of the new release scheme that both 
projects use?.
It's a two-edged sword.
If we always build nightlies from CVS-HEAD of the dependencies (which is 
essentially what Gump does), nobody ever has the chance to test the 
particular combination of JARs that we're actually going to include in 
the release.  Now, we can at least say please treat nightly build 
MMDD as a release candidate for Struts 1.2.1, and test it, with 
some assurance that the bits being tested actually represent what we'll 
actually ship.

I would be -1 on voting to call Struts 1.2.1 General Availability if 
we couldn't call Validator 1.1.3 General Availability -- but that 
isn't the same as being -1 on *releasing* Struts 1.2.1

The post-release vote on quality of a Struts release is just that ... a 
vote on its quality.  But we wouldn't have the option to call 1.2.1 
suitable for GA if Validator (or any other component) wasn't final 
yet, even if the quality was sufficient -- so I don't think we should 
even release it that way.

At any rate, I've seen lots of assurances in my catching up on mail that 
Validator 1.1.3 will-be/has-been released, so it should just be a short 
matter of time.

Joe
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Tonight's Nightly Build Dependencies

2004-07-06 Thread Craig McClanahan
Ted Husted wrote:
On Tue, 06 Jul 2004 00:41:13 -0700, Craig McClanahan wrote:
 

Can whoever is going to be release manager for this confirm the version numbers?
   

Did you want to go ahead and do it, Craig?
There are other things I really should be doing right now, but no one else was 
available.
Of course, if you are still recovering, I can finish up.
 

I'm down to under 6000 messages to catch up on (primarily commons-dev 
and struts-user) -- it would sure be nice if you could finish up, while 
I keep reading -- and, along the way, do some testing on struts-faces.

-Ted.
 

Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Tonight's Nightly Build Dependencies

2004-07-06 Thread Nicolas De Loof

Can't we use timestamp versions for validator ?

It is used by some maven plugins that are build using SNAPSHOT dependecies. When a 
release is done, the snapshot is
converted to a timestamp. Using this, no 'official' version of the dependency is 
needed (it only needs to be deployed on
ibiblio). Timestamp can be used to get dependecies sources from CVS if needed.

Using this, a 1.2.1 version of struts may be tagged. If any bug is discovered in 
validator using this *beta* Struts
version, it will help getting an official validator-1.1.3, and then a *stable* 1.2.x 
version of Struts.

Nico.

 Comment below

 Craig McClanahan wrote:

  I've updated my nightly build script (effective with the 20040706
  build) to use the following dependnet libraries, which I'm assuming
  corresponds to what we'll actually use in a Struts 1.2.1 release.  Can
  whoever is going to be release manager for this confirm the version
  numbers?
 
  antlr.jar 2.7.2 (*)
  commons-beanutils 1.6.1
  commons-collections 3.1
  commons-digester 1.5
  commons-fileupload 1.0
  commons-logging 1.0.4
  commons-validator 1.1.3 (**)
  jakarta-oro 2.0.7
 
  [SNIP]
 
  ** I'm temporarily using the version from Ted's public_html directory,
but I'm -1 on a Struts 1.2.1 release until this is voted to be a
  validator
release suitable for public use.

 This is a Chicken and an an Egg situation. Not enough people use
 Validator standalone for it to be promoted. Validator 1.1.3 only works
 with a nightly build of Struts. So to get the required number of users
 Validator will need in a released version of Struts to get the testing
 it needs to be promoted.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



Our name has changed.  Please update your address book to the following format: 
[EMAIL PROTECTED].

This message contains information that may be privileged or confidential and is the 
property of the Capgemini Group. It is intended only for the person to whom it is 
addressed. If you are not the intended recipient,  you are not authorized to read, 
print, retain, copy, disseminate,  distribute, or use this message or any part 
thereof. If you receive this  message in error, please notify the sender immediately 
and delete all  copies of this message.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]