Re: [RFC] 3.1 branching

Henrik Nordstrom wrote:
> On tor, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote:
>
>> So we have
>>> 1. Branch when trunk is considered a suitable startingpoint for getting
>>> to stable, and tag a x.y.0 release at the branchpoint (or at least set
>>> this version in configure.in).
>>>
>>> 2a. Release X.Y.0.1 when ready for testing
>>> 2b. Release X.Y.0.w as code gets better, w > 1
>>>
>> Don't forget the next step after (w>1 && w<12) is:
>> Branch X.Z.0 !!!!
>
> Ofcourse. trunk continues it's live and 1 restarts when suitable.
>
> The .0 releases is not a requirement, but may be useful depending on how
> the release matures after the branch, which heavily depends on the state
> of trunk at time of branching.
>
> But as soon as you branch the version needs to be labelled X.Y.0,
> with .1 being the "STABLE" release. But there does not NEED to be
> any .0.x release made at all if you as release maintainer do not want
> to,

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.

>
>> So why do we really need an extra .0 sitting on the end wasting space?
>>
>> 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.

>
>> The back-port workload becomes just too much for the few of us doing it.
>> Things won't get tested well, and stability goes backwards.
>
> Well, as soon as you have branched there will be backporting, and
> occationally forwardporting. Mainly bugfixes, and occationally a feature
> deemed important enough but which did not make it in time to the branch
> point but which made it in good time before the .1 "STABLE" release.
>
>> Lets just make STABLE release the highest of X.Y.W, .0 of that sequence
>> the pre-release beta code.
>
> 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.

>
> T
>> And flag anything we *really* need sub-releases
>> of with a temporary text or even just the snapshot datestamp. Preferrably
>> leaving those type of changes for a later X.Z release with testing time in
>> trunk.
>
> 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.

>
>> Keep in mind the whole W-level release cycle is going to be in the order
>> of months, with people who need long-term stability staying with
>> high-numbered older versions.
>
> Yes. Which is an improvement from the current 1.5 year. (which btw
> started when Squid-3 branched)

Yes, yes. I agree that 3.0 went badly before people got the momentum
going in PRE6.

Amos

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