Re: [RFC] 3.1 branching

On Wed, Sep 24, 2008 at 6:55 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On Wed, 2008-09-24 at 17:28 +0200, Kinkie wrote:
>
>> I don't like much not having a fixed "stable" marker much tho, what I'd do is:
>> - when major bugs are fixed, a .0 release point is taken. After that
>> during the stabilization phase, milestones are marked with an
>> additional numeral (e.g. 3.2.0.5)
>> - when STABLE level is reached, then a .1 release is taken (3.2.1).
>> After that, it's maintainance mode and new releases are marked by
>> incrementing the third numeral (e.g. 3.2.5).
>>
>> Advantages:
>> - it's fully-numeral
>> - it has a fixed "stable" marker (the .1 release).
>> - it doesn't change much the current numbering approach
>
> I like your proposal a lot more than the current scheme, but what is the
> value of a "fixed stable marker"? What a fixed marker like that would
> allow us to do that we cannot do by saying "stable" or "first stable"?

The message (I won't call it guarrantee) it would try to convey is:
"X.Y.0.W" means no critical or major bugs, feature-complete
"X.Y.1" means no known implementation bugs, feature-complete

The "version X.Y.Z for all Z > W" approach means that it's not easy to
tell what the state of a release is without knowing what W is for each
X,Y.

> The only use I can think of is that it would allow us to detect a stable
> release in a version number that was assigned 5 years ago (e.g., we will
> know that 3.1.3 was a stable release even 5 years from now). Since that
> old branch will no longer be supported by then, we should not need that
> information often. What other uses are there?

It's only a psychological thing. .0 "sounds" prerelease. Also the fact
that devel will not bump the patchlevel release "feels" like slowing
down and checking things out for the "first" number, 1.

By bringing your reasoning to the extreme, why not abandoning release
numbers altogether?
Version FOOBAR-XXXXYYZZ for XXXXYYZZ > WWWWKKQQ can be marked as
stable all the same (where FOOBAR is a string that defines the
featureset and thus the "release")

None of this has (or should have) any effect on the actual development
cycle, it's just conventions.

-- 
 /kinkie