On Wed, Jun 15, 2011 at 8:10 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Wed, Jun 15, 2011 at 15:08, Stefan Sperling <stsp_at_elego.de> wrote:
>> On Wed, Jun 15, 2011 at 02:33:04PM -0400, Mark Phippard wrote:
>>> Given that the most common distinction between alpha and beta is
>>> "feature complete" I have been arguing all along that the existing
>>> "alpha" release should have been labelled "beta". I would be +1 on
>>> changing that for the next release before we branch.
>>
>> There have been new (small) features and APIs added since alpha1,
>> e.g. mime-type detection with libmagic.
>>
>> Once we've branched we'll start the review process for backports,
>> which will put a definite end to new functionality being added.
>> I'd say just call the first release from the branch "beta" if there are
>> known blockers, and call it "RC1" if there are no known blockers.
>> Until we branch, we should keep calling them "alpha".
>
> I would still like us to consider a "beta" release, regardless. I
> would be very uncomfortable moving from alpha straight to RC1. I just
> don't have the confidence that the codebase is a 1.7.0 release at the
> point we branch.
That's understandable.
> ps. and if you *don't* think it is good enough for 1.7.0, then it sure
> isn't an RC1. if we roll RC*, then we can't say "oh, but it isn't
> final. we'll have bugs to fix." that isn't an RC. seen too much of
> that nonsense in the past...
Completely agree. A release candidate is a *candidate* for release,
and if we wouldn't be willing to release it as the final, it's got no
business being an RC. After we branch, we can take the temperature of
the community, and determine which of a beta or rc is warranted. (I
suspect it will be a beta.)
-Hyrum
Received on 2011-06-15 22:20:02 CEST