My understanding was that we may vote a relase as "beta" initially if, for example, it has alot of new functionality and then if no issues come up vote again to upgrade the quality to "GA".
Whats happened so far since this was introduced was that either releases have been voted "GA" straight away (since the changes from the previous release are not large), making a second vote unnecessary or releases have been voted "beta" because of known issues and therefore have no prospect of ever being upgraded.
From memory this was based on the type of process that Tomcat uses and
thats what we were trying to mirror. Niall On 5/5/06, Ted Husted <[EMAIL PROTECTED]> wrote:
I think the (B) vote is a copy-and-paste error. The form element was introduced between 1.25 and 1.26, but its never been used. The (B) lists are tasks that we only need to do after the quality is determined to be GA, so the one-and-only vote comes in the middle. -Ted. On 5/4/06, Don Brown <[EMAIL PROTECTED]> wrote: > I'm preparing to draw the Struts Action 1.3.2 release quality vote to a close, > but as I look at the release plan, I see it has us voting twice on the same > release for the same quality vote (vote a and b). Why is this? Seems to me one > vote should be plenty. > > Don > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- HTH, Ted. ** http://www.husted.com/ted/blog/ --------------------------------------------------------------------- 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]
