We can have as many phases as we like. We often vote a distribution as
"beta" first, and announce it to the use list, and then depending on
that experience, vote again and reclassify the "beta" to "GA".

A key idea is that we should be releasing the same set of bits that we
tested, without change. Aside from the people here, our only other
testing group are subscribers to the Struts user mailing list. We need
to release a set of bits to that group, let everyone test it, and if
the bits are joyful, declare them GA. The quality we assign to a
release should not be a matter of personal belief, it should be
determined by what we have found through actual experience in the
field.

Of course, we could do something like distribute a set of bits tagged
as a "release candidate", and  if the RC is found joyful, we could
copy or rename the tag, build a distribution from the same tag, and
call it the GA. But, of course, those would not be the same bits, only
very similar bits. Even if we assume that we can build an equivalent
distribution from the same tag under a new name, all the helpful souls
who have been using these bits in production would have to change JARs
again. An approach like this simply creates more work for everyone,
without producing a single tangible benefit. (How rude!)

If later we find a problem with a release, we should also downgrade it
from GA to beta, or Alpha. Actually, we should do this with the
releases prior to 2.0.9, since I don't think any of us would recommend
that those distributions be used in production.

-Ted.

On 10/2/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
> It is a pretty interesting process, but probably the vote call should be
> changed. There will be a "two-phase" vote, where:
> - in the first phase, we vote if we want the test build released (without
> mentioning the quality);
> - in the second phase we vote the quality.
> Thoughts?
>
> Antonio
>


-- 
HTH, Ted <http://www.husted.com/ted/blog/>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to