struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <hus...@apache.org>
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.

http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=15736%2C16019%2C11021%2C15044%2C15799%2C15883%2C15913%2C16073%2C15816%2C15912%2C15916%2C15935%2C15969%2C16067%2C16104%2C16207&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&version=1.1+Beta+3&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=reuse+last+sort

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

http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=LATER&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&version=Nightly+Build&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time

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.

<http://jakarta.apache.org/site/guides.html>

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.

-Ted.


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message