[rfc] six-month stable release cycles

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russ Brown wrote:
> On Wednesday 29 July 2009 01:39:49 am Martin Pool wrote:
>> A longer stable cycle has often been requested.  I think we should do
>> it, now, along the lines of this document.   (It's in devnotes and
>> also as a pdf for those who like it that way.)
> 
> I agree. My only question regards version numbering: unless I've misread 
> something, you seem to be ignoring the middle part of the version number. i.e. 
> 2.1.0 etc.
> 
> I personally very fond of the postgres-style [1] of numbering. The last digit 
> denotes a bugfix release, so 2.1.x has the same (intended) functionality 
> regardless of the value of x. They guarantee that these releases don't change 
> functionality unless required in order to fix a security bug.
> 
> The middle digit denotes general functionality changes: performance and 
> feature enhancements.

As others have noted, I find it a bit strange that we would always be on
a X.0 release, rather than a X.1, X.2

We *could* define it in all sorts of different ways. Martin and I
discussed having the 6-mo release be a X.1 and then the one year be (X+1).0

or we could have the new default disk format be (X+1). Which to date has
been a bit closer to a 18-mo change. So the numbering would be:

2.0.0 - 2.0.1 - 2.0.2
 \
  2.1beta1 - 2.1beta2 ... 2.1rc1 - 2.1.0 - 2.1.1
                                   \
                                    ...

The main problem is that I don't think we'll know at 2.1beta1 that this
is going to be the release that we are going to change the default
format in 6 months. So we won't really know whether it is 2.1beta1 or
3.0beta1. (Ideally we shouldn't have to predict that sort of thing so
far in advance.) However, as it is a fairly major change, maybe we can
predict it with some level of accuracy.


Gut feelings:

1) Changing the major version every 6 months is 'too fast'
2) Changing a major version every 18months and changing the minor
version every month seems about right, but means you get X.17, where it
is nice to have X.Y w/ Y <= 9.
3) I prefer beta + rc rather than X.90 meaning RC.
4) It might be nice if X.Yrc1 was a regular 1-month before the X.Y
release, rather than doing weekly rcZ releases until final is out. It
feels a bit more regular to me. With the caveat that rc2 may come out
one week after rc1, but that we expect -final to come approx 1 month
from the rc.

As for syncing with Ubuntu, it would seem to me that whenever we would
want to release -final to make sure it has "time to stabilize for
Ubuntu+1" we would just put the rc1 release at that time.



In the end, I think *my* preferred numbering is:

2.X	 - stable release (every 6mo)
2.YbetaZ - monthly dev release in preparation for the next stable 2.Y
           release
3.0	 - new default disk format, happens somewhere in the 12-24 mo
           from the time we release 2.0

3.0rcZ   - A monthly dev release with the new format set to be the
           default. This *might* be 3.0betaZ but that may be too soon.
           Perhaps 3.0betaZ is when the new format is starting to
           stabilize and is available for general testing?

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpwlHEACgkQJdeBCYSNAAMVQACcCRtRweo8+mzcugbUFXMMnRbb
kEUAnj1PJBf+cXK2dZ1YJgS1ATwPxahG
=XDIZ
-----END PGP SIGNATURE-----