Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1

[Ted Husted]

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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>