[Dev] Milestone numbering going forward

Philippe Bossut pbossut at osafoundation.org
Wed Nov 30 20:52:03 PST 2005


As one of the persons in the room when we talked about version numbering 
(that was way back when Fogel's book light didn't reach us and we had 
private conversations...), I feel somewhat guilty of the situation. 
Aparna and Heikki explained why we tried to improve the existing system. 
Alec and PJE both made proposals for a backward and forward systems 
(without taking sides) and we have at least one -1 on the proposal. So 
we're kind of staled.

It seems to me we can converge toward a consensus if we have a yardstick 
to decide between forward and backward numbering. The objective of this 
e-mail is to provide such a yardstick (I hope).

One point that was made during the initial meeting was that we didn't 
expect the "trunk" to be stable enough that we would be able to create 
release versions from it predictibly. IOW, our expectation was that once 
0.6 was branched, we would create 0.6.x updates (bug fixes, minor 
updates, demos) from the branch only while the trunk was undergoing 
massive changes (for 5 to 6 months). The 2 branches would live 
concurrently and be productive for a long time:


In that case, it makes sense to use a forward numbering system for the 
trunk (x=7 in the here above artwork) so that there's no ambiguity in 
people minds when talking about an "0.6.x" version (branch, stable) or 
an "0.7.x" version (trunk, dev, experimental).

This is the graph we had in mind (and on the whiteboard) and this is why 
we choose that numbering scheme.

Now, several months later, there's a consensus (at least in the Apps 
team) that each monthly or bi-monthly milestone should be fully usable 
(modulo cutting edge new features may be). This will certainly require 
us to spend an extra week or more for each milestone to polish and 
stabilize the code but we see lots of value to stabilize as we go and 
get new features in the hands of all users (and not only those building 
from code) earlier rather than later. So the tree could look like 
something like that:

                 /-0.6.0               /-0.6.1     /-0.6.2
                /                        /              /

In that case, a backward numbering scheme is clearly better (x=6), at 
least till we get to 0.7 alpha quality on the trunk (feature complete at 

So the question is really one of dev process: in the next 6 months, do 
we think we will create updates from the current 0.6 branch only or that 
we should be more hardcore on our milestone process and do them from the 
trunk? IOW, the choices are:
1- Forward: The 0.6 branch is the only place to create incremental 
updates (trunk will be too unstable) and we'll use forward numbering on 
the trunk (0.7xxx).
2- Backward: The trunk is the place to create incremental updates, we 
are committed to produce high quality milestones moving forward and we 
then need to use a backward numbering scheme (0.6xxx)

Once this is decided, we can spell out the rules (PJE has apparently 
thought a lot about this) and I'm sure we'll converge rapidly (so don't 
pay attention to the fact I used "m" here above, we'll work that out later).

I have to say that, at the time of the meeting, I was clearly in the (1) 
camp but that now, I think we should go with (2). Note BTW that going 
with (2) also means that big destabilizing work should likely be done in 
a dev branch and that milestones must be feature driven (so that not too 
many half bake stuff cripple any milestone).

Would people care for a vote?

- Philippe

Alec Flett wrote:

> So here's my vote on this:
> 1) if we go with a backwards numbering system, then we use "M" - 
> 0.6m1, 0.6m2, ... 0.7. This allows us to release a 0.6.1 (lets say, 
> hypothetically for PyCon 2006 we might need to tweak the branch for 
> some development work..)
> 2) if we go with a forwards numbering system, then we use "alpha" or 
> something to indicate that we're leading up to the release - 
> 0.7alpha1, 0.7alpha2,...0.7.
> In either of these schemes, I would love to also see subversion 
> revision numbers (r8403) added to the version.. (0.6m1-r8403 or 
> 0.7alpha1-r8403)

More information about the Dev mailing list