Re: [RFC] 3.1 branching

> On Thu, 2008-09-25 at 16:20 +1200, Amos Jeffries wrote:
>
>> trunk (3.1.0)
>> -> sept 30: branch with 10 new features
>> release 3.1.0
>> (makes trunk now 3.2.0)
>> -> oct 30: everything found 'stable'
>> release 3.1.1
>> -> nov 30: 10 new major+ bugs fixed :-(
>> release 3.1.2
>> (move 3.1.1 down to obsolete list)
>> -> dec 30: 2 new major+ bugs found
>> release 3.1.3
>> -> jan 1 : branch with 9 new features
>> release 3.2.0
>> (makes trunk now 3.3.0)
>> -> feb 1: everything found 'stable'
>> release 3.2.1
>> release 3.1.4 final bug fixes.
>> -> ...
>>
>> trunk continues its merry way getting new features the whole time as
>> 3.*.0
>> without any flag points.
>
> So how do we tell users to try something between 3.1.0 and 3.1.1? Refer
> to some specific daily snapshot? Kinkie+ scheme would use numbered beta
> releases: 3.1.0.1, 3.1.0.2, etc.
>
> I think numbered releases are better than daily snapshots for asking
> users to try something: "Argh! Somebody committed a bug 5 minutes before
> the snapshot we thought we would recommend to the user. Let's wait
> another day and hope that it does not happen again. People! Please do
> not commit anything because we need a clean daily snapshot!".

Thats all in trunk. We are talking numbering systems for the branches.
To which the only commiter should be the branch maintainer. We can make a
new clean snapshot at any point if its really warranted, even to the point
of calling it a 3.1.0.1 'release' 3 times in one day.

That said, maintainers can do the same for trunk too if convinced its
worth the trouble.

>
>> (makes trunk now 3.2.0)
>> (makes trunk now 3.3.0)
>
> I am not sure what those mean. Trunk is a trunk. 3.2.0 is the first
> release on a 3.2 branch, right? I am ignoring those for now.
>
>> We may reach 3.1.6 if things go badly, or if new features get developed
>> really slowly. But I don't think we will get enough checkpoints in the
>> devel cycle to warrant two layers of .0.1 -> .6.2
>
> The extra "development release" layer in Kinkie+ scheme is only used for
> 3.1.0, never for 3.1.6 or other non-zero releases.

This is a contradiction of your earlier how do we tell users to try
something between 3.1.0 and 3.1.1?"
The 'please try X' request is done as often after 3.1.1 as before.
We come back to the problem of until squid is 100% major bug free for all
users (now and in future) it never actually qualifies for that 3.1.1
rating.

Under my scheme, we would not grant such development test points a full
version number, they can get a rc1, rc2, etc (or as at present a
'20080912') if needed.

>
>> People seem happy with the release approach and timelines, just not the
>> current bad naming scheme which implies releases are guaranteed STABLE
>> when in fact only a bug fix improvement.
>
> Well, there are several problems with the current scheme, but I think we
> should preserve the notion of a "stable" state of the branch. It is not
> a guarantee, but it allows users to select the right branch/version to
> deploy. In Kinkie+ scheme and in your scheme, the branch is considered
> stable when 3.1.1 is released. Before that, there are big known bugs.
> After that, there should not be any and those that appear should get
> higher fixing priority.
>
> The only significant difference I see is that you want folks to use
> daily snapshots during "development" stage of the branch and Kinkie
> wants sub-numbered releases.

Yes, pretty much.
If you look at the changeset pages for each 3.0 release so far, there are
fixes for some very major bugs in there as far as 3.0.STABLE7.

If we had run a whole cycle of 3.0.0.N (aka 4 years of testing PRE1 ->
RC2), we would have still probably have released 3.0.1 (aka 3.0.STABLE1)
with those bugs in. Or maybe gone straight from 3.0.0.16 to 3.1.0.1 this
month

I don't realistically expect 3.1 to be perfect either.

I'd rather have fixed point releases (3.0.1) based on some known workable
code, and a pile of sequentially tagged bundles of 'maybe dodgy code' on
top for new un-tested bug fixes.

Amos
Received on Thu Sep 25 2008 - 05:49:38 MDT