directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [Version Numbering scheme] was: Version numbering and roadmap planning
Date Mon, 07 May 2007 06:29:06 GMT

On May 5, 2007, at 5:18 AM, Emmanuel Lecharny wrote:

> 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 ?


This all sounds a bit abstract to me.  Can you provide some concrete  
uses cases that provide compelling reasons to have a stable/unstable  
releases occurring at the same time?  Thanks!


Regards,
Alan


Mime
View raw message