Re: [RFC] 3.1 branching

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 24 Sep 2008 23:23:13 -0600

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

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

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

Thank you,

Alex.
Received on Thu Sep 25 2008 - 05:23:25 MDT

This archive was generated by hypermail 2.2.0 : Thu Sep 25 2008 - 12:00:06 MDT