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.
