Re: [RFC] 3.1 branching

Henrik Nordstrom wrote:
> 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)
>

Hmm, so rolling DEVEL + PRE + RC into one version called a.b.0.N
Well, I'm a little doubtful but can't argue against that yet.

>>>> 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.

Yes. Still worried that people are mixing the trunk/before
stable1/post-stable1 timespans and what can/can't be done.
But will leave it and see what happens when we trial this.

Amos

-- 
Please use Squid 2.7.STABLE4 or 3.0.STABLE9