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]

Reply via email to