On 2/7/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 2/6/07, Don Brown <[EMAIL PROTECTED]> wrote:
>
> 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.
Isn't a feature of the current release practice that you could vote a
particular x.y.z release as "beta" now, but later hold another vote to
upgrade it to GA status later (i.e. without requiring another release)?
Don's success with it is great ... but that is only one data point. Having
10-50 people report back success would seem to mean it's time to go back and
give that release a better report card.
Don
Craig
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.
I see two clear stages:
- a product that is ready from developers point of view
- a product that gets its users acceptance
An OSS project can take the same approach or not, and this is up to
its management. However, I feel that a project that would like to be
widely used cannot be labeled as released version without the user
acceptance.
I understand Don's concern about how these steps should be managed,
but I think this is not a very complex process:
- developer's ready version: beta
- (after a scheduled period during which only fixes go in if necessary): GA.
./alex
--
.w( the_mindstorm )p.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
