Re: [RFC] 3.1 branching

On Wed, Sep 24, 2008 at 4:45 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote:
>> On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote:

> The DEVEL label is not needed indeed, but I was talking about code
> states. I understand now that you use the PRE state for a different
> purpose. Please note that your definitions of DEVEL and PRE differ from
> the ones on the web site.
>
> The most annoying thing, IMO, is that the official and your definitions
> above have two fuzzy lines for DEVEL and PRE states: stability and
> features. One fuzzy line is tolerable, but two make things really
> confusing.
>
>> > > The non-major but important bugs can be fixed during DEVEL and PRE
>> > > cycles. Branching is about features not bugs.
>> >
>> > Agreed, except I do not think we should have any known important bugs
>> > when doing the first PRE (if we do PRE at all).
>>
>> Yes. It's not much use in releaseing a PRE with known major blockers.
>
> But your definition above says we are still hunting down some bugs. It
> does not say there are no major bugs left.
>
> How about this:
>
> Trunk: Experimental code and new major features are being added. Use
> daily snapshots (e.g., HEAD-YYYYMMDD). No label.
>
> ... time passes, more features are added ...
>
> Branching point (e.g., 3.1): All major features are in. Use daily
> snapshots (e.g., 3.1-YYYYMMDD). No label.
>
> ... time passes, all known major bugs get fixed ...
>
> First numbered release (e.g., 3.1.0): All known major bugs fixed. Could
> be labeled a "beta" or "development" release if needed.
>
> ... time passes, more beta releases are made, with fewer bugs ...
>
> Branch first marked as "stable" (e.g., 3.1.5): The last numbered release
> turned out to be stable!
>
> ... time passes, the stable branch is maintained ...
>
> Branch marked as "end of life" or "no longer supported".

This is a bit like rehashing an old discussion, I'll however give it a
shot but not discuss it further.
I'm not a particular fan of DEVEL/PRE/RC/STABLE labels.

I like your idea about labelling the branching point and keeping
timestamps around for the head and post-branching stabilization phase.

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

My 2c; I won't waste more of anyone's time
(re-re-re-re-re-re)resurrecting this discussion.

-- 
 /kinkie