Hi,
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:
<ascii-art>
/-0.6-------0.6.1-----0.6.2-----
/
0.5.m8---/-0.x.m1-------0.x.m2----0.x.m3-----0.7
</ascii-art>
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:
<ascii-art>
/-0.6.0 /-0.6.1 /-0.6.2
/ / /
0.5.m8---/-0.x.m1-------0.x.m2----0.x.m3-----0.7
</ascii-art>
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
least).
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?
Cheers,
- 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)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
