Re: [RFC] 3.1 branching

On tor, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote:

> So I should simply say 'X is how we are doing it'? I think not.
> Kinkie has somehow convinced Alex of a different way of numbering then
> simply omitting the word 'STABLE', I'm pondering it but need a good
> reason to agree.

No, it's simply that, but keeping the "PRE" state and reflecting this in
the numbering by using .0.X. The other states are dropped from the
numbering.

3.1.PRE1 -> 3.1.0.1
3.1.PRE2 -> 3.1.0.2
3.1.STABLE1 -> 3.1.1

And that we keep an indication on the web site on which releases is
currently considered stable for production use. (I would guess usually
the latest release + maybe one or two patch releases back, depending on
what bugs have been fixed)

> >> I have no intentions of maintaining anything other than:
> >> trunk + latest X.Z.n + most stable X.Y (if X.Z.n < X.Z.1)
> >
> > Nobody has said anything else.
>
> ? the alternative to this I'm arguing against has another layer of
> formal .N releases.

How?

> > That's exactly what we are saying.
>
> By my reading, Alex and Kinkie are going on about a whole lot of *.0.N
> releases required if we don't consider any particular code STABLE.
> Like they are confusing trunk stabilization with branch stabilization.

There will likely be a couple of iterations from the branchpoint until
we are happy to label the release stable. My estimate is 2 such
releases.

> > We have not said anything about any sub-releases after the .1 "STABLE"
> > release, except for the possibility of a "Release Candidate" indication
> > in the web site and/or informal announcement.
>
> Alex has indicated his understanding of NO sub-numbering after X.Y.1,
> which equates to no -RC.

The RC indication is NOT part of the numbering. It's a process. If a
release candidate fails for some reason then that release never gets
promoted to stable and we move on to the next number.

Regards
Henrik