directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject [Version Numbering scheme] was: Version numbering and roadmap planning
Date Sat, 05 May 2007 12:18:15 GMT
Hi Chris, Alex, all,

I will keep the previous convos in this mail, to let people being able 
to get all the different points together. Feel free to just reply only 
on specific points in the next mails, using the [Version Numbering 
scheme] prefix in the mail.

y comment are at the end of this mail.

Alex Karasulu a écrit :

> Hi Chris, all,
> Just as a heads up we will be publishing some of the conversations 
> we've had
> about a possible road map and initiatives.  More in line ...
> On 5/3/07, Chris Custine <> wrote:
>> Now that there is some discussion of the roadmap and feature list for 
>> the
>> next few releases of ApacheDS, I am wondering if anyone is interested in
>> discussing the versionin numbering and release scheduling for the 
>> next few
>> releases?
> Yeah I'm very interested in some of the points you made during the
> conference.
> There are two specific issues that come to my mind with the current
>> methods.  First of all, with a fairly extensive and aggressive list 
>> of new
>> features soon to show up on the roadmap, I am wondering about the 
>> viability
>> of the odd/unstable and even/stable numbering scheme.
> I'm very fond of this scheme because it allows us to tell users that
> interfaces and backing stores can be changed during an unstable release.
> This removes the need for us to make sure we're backwards compatible with
> previous interfaces and partition data formats. However others might not
> feel this is all that useful.
> I am thinking that it may be better to go to a flat versioning scheme 
> with
>> no built in meaning, other than bug fixes releases and new feature
>> releases....  To be clear, I am saying that 1.6, and 1.7 would both be
>> production releases and the user would not have to know any special
>> meaning....  1.6.1, 1.6.2, etc. would be bug fixes, etc.  The reason I
>> suggest this is to make room for release early/release often type of
>> releases and to make the version numbers much easier to comprehend.
> Well we can release early and release often regardless of this even/odd
> thing.  I don't think the two are coupled.  Perhaps you mean releasing
> stable versions more often instead of being stuck in a feature release
> branch?
> Right now we hold back for months even though we release feature 
> releases in
> an feature introduction branch like 1.5.x.  These release are not
> necessarily unstable though.  So perhaps we should just stop calling it
> unstable or even bother with feature/bugfix branches?
> If we combine the first idea with breaking the roadmap into smaller 
> chunks,
>> we can manage the pace of change much more easily and introduce new 
>> features
>> and enhancements without the overhead of managing the other versioning
>> scheme and the two phase releases (unstable stable).
> Not sure if there is much overhead here tho.  Someone mentioned that 
> the new
> scheme of releasing features with stable releases would create more 
> overhead
> for maintaining and supporting these releases.  Also there is the
> documentation nightmare of tracking which features correspond to which
> release.  Although I must admit that I kind of liked this idea of 
> releasing
> stable versions with new features these considerations scare me a bit.
> Mainly I am just suggesting a simplification of the version numbering and
>> roadmap planning to allow us to do more releases with smaller changesets
>> while still maintaining the ability to easily to bugfixes on release
>> branches in SVN.  If we release often, merging bugfix branches into the
>> development branch is much easier and has less merge conflict, and the
>> version numbering change will help make that a reality.  I do realize 
>> the
>> need to have some features in the builds that we don't exactly indend 
>> for
>> production use, but instead of letting that requirement dictate our
>> versioning, perhaps we could label those features as experimental in the
>> documentation or find a similar solut ion?
> Yes this is an option (re: labeling certain features as experimental).
> Perhaps we can get more people to chime in on this.  I'm torn between the
> two ways.  Each has pros and cons.
> Obviously this is a big topic that is sure to start much discussion, 
> so does
>> anyone else have any strong opinions on this?
> Yep we need more feedback.
> Alex

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 ?


View raw message