struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <>
Subject Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Date Sun, 19 Jan 2003 21:15:55 GMT
Martin Cooper wrote:
 > Given that there have been around 50 commits since 1.1-b3, and there
 > arecurrently 21 Bugzilla issues outstanding, in all honesty, I would
 > find it hard to claim that 1.1-b3 is really a release candidate.
 > I would prefer to take what we have now, or in a (very) short time
 > from now, and call that a release candidate. Calling 1.1-b3 a release
 > candidate is, in my opinion, tantamount to lowering our standards, or
 > at leastappearing to do so in the eyes of our customer base. That is
 > not a goodprecedent to set.

First, sorry about all the Bugzilla activity, but I wanted to be sure we 
knew where we stood before trudging on.

As it stands, we have 8 open issues against B3.

I've reviewed the rest and marked anything that could wait without 
compromising quality as RESOLVE LATER against the nightly build.

All but 3 are enhancements. Two of these can't be confirmed right now, 
and the other involves message resources in modules. It may be an 
enhancement, but I wasn't sure.

My suggestion would be to schedule a Beta 4 against the nightly build, 
and then to not hesitate releasing B4 as Struts 1.1. final if it flies. 
The idea being we suspect that B4 is a "defacto" release candidate, and 
may go from B4 to Release, if appropriate.

I think we have giving everyone fair warning about an upcoming release 
and we could just skip the Release Candidate stage if we can bring out a 
solid beta.

One thing I would discourage would be cutting a Release Candidate if we 
"strongly suspect" that we will need another RC.

One definition of Release Candidate is

o "Release candidate" means we think this build is it, and will only 
change high priority bugs -- and API changes are totally verbotten.


and I would not want to dilute this definition to mean anything less 
that a code base that we honestly believe is ready for release.

I would much prefer to go from a Beta to a Release without a Release 
Candidate than to cut a Release Candidate if we do not honestly believe 
it is ready for prime time.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message