On May 5, 2007, at 5:18 AM, Emmanuel Lecharny wrote:

Ok, I agree with a lot of Chris points. We have to find an easier way to enumerate versions, and the odd/even scheme does not fit me a lot, because the semantic is not very clear. However, I also think that Alex is right when it comes to have stable/unstable revisions (keep in mind that unstable != buggy, but unstable == experimental)

We have had a convo with Alex this morning while we were moving to the airport : what about using the X for each 'stable version ?

Like : 1.0.z, 2.0.z, 3.0.z... are stable versions (X.0.z will *always* be stable versions)

Now, for experimental/unstable versions, I suggest to use the Y part :

1.5.z, 2.5.z, ... X.5.z will be experimental versions

The idea behind is to express the fact that we are just in the middle of two stable versions. We won't have 1.6.0, but a 2.0.0. If we have to add a new feature, or fix a bug, then we switch to the next Z number : from 1.5.0 to 1.5.1, or from 2.0.0 to 2.0.1

To make it clear, we will use the X.Y.Z scheme where :

X : major version

Y : if 0, then the version is stable, and feature completed. If 5, then this is an intermediate version

Z : used for bug fixes if Y=0, or for new features or bug fixes if Y=5.

1.5.2 => new features has been added to 1.5.1

2.0.3 => stable version 2, with third delivered set of bug fixes.

wdyt ?

This all sounds a bit abstract to me.  Can you provide some concrete uses cases that provide compelling reasons to have a stable/unstable releases occurring at the same time?  Thanks!