Well, two comments here. First, how many beta releases do we need
before it is time for a GA? I think we've been at beta quality since
2.0.1 and, yes, it has been helpful to weed out issues, but now with
several large applications running Struts 2 and no significant issues in
JIRA, I think we are ready for GA.
The second is a general comment about this new release process. I think
you are right that we'll have to agree to disagree here, cause I've
always disliked this idea of doing a release then voting on it later.
If we are taking that backwards-looking approach even farther and
basically automatically giving releases a "beta" label until some
undetermined future date when we vote again, then I really must object.
I can understand the value of a test build and vote a few days after to
ensure that the release process went off smoothly and all the important
bits are in there. I may not particularly like it, but I agree it is
necessary. What I find disturbing is that we would make a habit of
waiting till weeks/months after the fact to label it GA. If the release
is built, we test it and find nothing wrong, I think we should label it
GA and move on. If bugs are found after the fact, then let's roll
another release. I'm concerned that the backwards-looking way of
thinking will result in a project that very rarely gets anything out to
its users. I think open source projects work best when they release
early and often, even if they may find bugs in it later on. And before
the comment is made that test builds or even beta releases _are_
following the release early/often pattern, it certainly isn't true for
what I'd argue that is the majority of developers who can't touch a
product without the GA label.
I really hope we can find a productive balance between the need for
stability and need to keep the project moving at a healthy pace. Let's
not fall into the Struts 1 trap of being overly conservative, but
instead get out quality releases quickly and often.
Don
Ted Husted wrote:
We might have to agree to disagree. I believe a beta vote is warranted
when someone believes the code is ready for testing outside of the
development group. Personally, I am not in favor of passing a set of
bits straight to GA without a beta cycle, especially when a release
series hasn't seen a GA release yet. The term "General Availability"
should mean that we feel it is ready for us by the general public, not
just that we were able to use it ourselves. Of course, other PMC
members may have different viewpoints.
Remember, voting beta now is not the final disposition. It simply
means that we can announce the release to the user list and encourage
wider testing. If the reports come back joyful, then we can decide to
apply the GA stamp.
In the meantime, we can continue to roll new releases. I'd be happy to
run one every week or two, so long as there is something to put into
the notes :)
-Ted.
On 2/6/07, Don Brown <[EMAIL PROTECTED]> wrote:
I disagree; you shouldn't vote beta just because you haven't ran the
code in production. A beta vote should be reserved for the case where
you don't believe the quality is at the level of a GA release, and there
should be specific issues you can point to that you feel need to be
resolved first. If you have downloaded the release, ran it through
whatever tests you deem appropriate, and it passes with flying colors,
then a GA vote is warranted.
Don
Ted Husted wrote:
> Beta is also an option :)
>
> On 2/6/07, Ian Roughley <[EMAIL PROTECTED]> wrote:
>> +0 for GA. I have some testing code that looks good, but no
production
>> code that has been converted.
>>
>> /Ian
---------------------------------------------------------------------
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]
