directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: Version numbering and roadmap planning
Date Fri, 04 May 2007 16:38:39 GMT
Hey Guys,

Suppose each new version number for ApacheDS
corresponded to a set of bug fixes and new features,
and these release were always assumed to be as
stable as possible (Well tested according to
defined testing criteria).

So for release 1.5.5 the Changes.txt would just
list all the new features included, and any bug fixes.

These would be assumed to be stable.  Thus SNAPSHOTS/nightly builds
would be the only builds that would be tagged as "Experimental/untested".

So in order for a new feature to be included in a release
it would have to be tested according to defined testing criteria, 
otherwise it just stays in the trunk.

If desired the roadmap could target certain features for certain
release numbers.  This does bring up the question of whether
the feature has to be complete (Tested) for it to be included
in the release.

Personally I think if someone wants to add a feature targeted at a 
version release, they should also be responsible for making sure
the feature is solid by a certain date.  This is so that the
feature does not hold up the release.  Otherwise, the feature
should just be on the roadmap, without being tagged to a certain
release.

Cheers,
- Ole






Alex Karasulu wrote:
> 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* <chris.custine@gmail.com 
> <mailto:chris.custine@gmail.com>> 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
>  
> 

Mime
View raw message