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 ...
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 solut ion?
Obviously this is a big topic that is sure to start much discussion, so does anyone else have any strong opinions on this?