directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Custine" <chris.cust...@gmail.com>
Subject Version numbering and roadmap planning
Date Fri, 04 May 2007 00:56:46 GMT
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?  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 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.

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).  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 solution?

Obviously this is a big topic that is sure to start much discussion, so does
anyone else have any strong opinions on this?

Chris

Mime
View raw message