[Version Numbering scheme] was: Version numbering and roadmap planning

[Emmanuel Lecharny <el...@apache.org>]

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 <ch...@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
>

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 ?

Emmanuel

Re: [Version Numbering scheme] was: Version numbering and roadmap planning

[Alex Karasulu <ak...@apache.org>]

OK cool.  Perhaps others can sound off on this approach?

Alex

On 5/8/07, Chris Custine <ch...@gmail.com> wrote:
>
> Oh btw will this impose any issues with OSGi versioning?  Just thought I'd
> > ask that.  Don't know what happens with the beta/alpha designators.
>
>
>
> No this won't be a problem...
>
>
> On 5/8/07, Alex Karasulu < akarasulu@apache.org> wrote:
> >
> > Hiya Chris,
> >
> > On 5/7/07, Chris Custine <ch...@gmail.com> wrote:
> > >
> > > My main concern with all of the implied meaning in the release numbers
> > > is that the users will not pay attention to it, and eventually get irritated
> > > with it when they have an issue with a new feature and we tell them that
> > > they probably shouldn't play with their shiny new toy in production.
> >
> >
> > Yeah true.  This is not a good situation to be in.
> >
> > Last night it occured to me that maybe we have all overlooked an obvious
> > > solution that could make everyone happy.  With the unstable feature releases
> > > we are basically talking about a very formal beta testing phase.  So maybe
> > > we should call these releases beta releases, but without any special meaning
> > > embedded in the numbers.  So after a stable release of 1.6, why don't
> > > we do the typical release branch for bugfixe releases like 1.6.1, work
> > > off of the trunk for the next major release and do releases from trunk as
> > > 1.7 beta 1, 1.7 beta 2, etc. until things are stable.  Or at least
> > > something along these lines.  I think this will make much more sense to the
> > > users and allows the Directory project to introduce new features in beta
> > > releases without worry of tripping up any bleeding edge users using beta
> > > releases.
> >
> >
> > I think I like this.  So the alpha would be for feature releases that
> > may be somewhat destabilized.  The beta would be for releases that are being
> > stabilized or optimized before a stable release?
> >
> > What do others think?
> >
> > There are a couple of small drawbacks.  Even though I see other projects
> > > doing it, we shouldn't release beta builds on the main maven repo, although
> > > I am not sure this is a hard rule, I think it is a general practice not to
> > > do it.
> >
> >
> > Actually this is not an issue.  I think we can release beta's as long as
> > it is an officially voted on release.  It just signifies that new features
> > are introduced before stabilizing or hardening the server.
> >
> > However this leads back to the main argument that the special unstable
> > > build numbers are misleading when deployed to maven repos because the user
> > > may not realize what the build number means and could use it in a production
> > > app.
> >
> >
> > Well the beta marker as you suggest does explicitly give a signal to the
> > user.  I like it.
> >
> > I hate to spend so much time on this type of subject,
> >
> >
> > This is very good tho - you're helping us answer some critical
> > questions.
> >
> > but I just want to make sure that the users see things clearly and that
> > > we don't impose any special rules on them with released versions.  The beta
> > > solution may not be the prettiest, but there is a lot of precedent with
> > > other projects and vendor products out there and at least this way the users
> > > know exactly what they are getting when they download and install  ;-)  So
> > > consider this just another suggestion...
> >
> >
> > This is a good suggestion really.  Oh btw will this impose any issues
> > with OSGi versioning?  Just thought I'd ask that.  Don't know what happens
> > with the beta/alpha designators.
> >
> > Alex
> >
>
>

Re: [Version Numbering scheme] was: Version numbering and roadmap planning

[Chris Custine <ch...@gmail.com>]

>
> Oh btw will this impose any issues with OSGi versioning?  Just thought I'd
> ask that.  Don't know what happens with the beta/alpha designators.



No this won't be a problem...


On 5/8/07, Alex Karasulu <ak...@apache.org> wrote:
>
> Hiya Chris,
>
> On 5/7/07, Chris Custine <ch...@gmail.com> wrote:
> >
> > My main concern with all of the implied meaning in the release numbers
> > is that the users will not pay attention to it, and eventually get irritated
> > with it when they have an issue with a new feature and we tell them that
> > they probably shouldn't play with their shiny new toy in production.
>
>
> Yeah true.  This is not a good situation to be in.
>
> Last night it occured to me that maybe we have all overlooked an obvious
> > solution that could make everyone happy.  With the unstable feature releases
> > we are basically talking about a very formal beta testing phase.  So maybe
> > we should call these releases beta releases, but without any special meaning
> > embedded in the numbers.  So after a stable release of 1.6, why don't we
> > do the typical release branch for bugfixe releases like 1.6.1, work off
> > of the trunk for the next major release and do releases from trunk as
> > 1.7 beta 1, 1.7 beta 2, etc. until things are stable.  Or at least
> > something along these lines.  I think this will make much more sense to the
> > users and allows the Directory project to introduce new features in beta
> > releases without worry of tripping up any bleeding edge users using beta
> > releases.
>
>
> I think I like this.  So the alpha would be for feature releases that may
> be somewhat destabilized.  The beta would be for releases that are being
> stabilized or optimized before a stable release?
>
> What do others think?
>
> There are a couple of small drawbacks.  Even though I see other projects
> > doing it, we shouldn't release beta builds on the main maven repo, although
> > I am not sure this is a hard rule, I think it is a general practice not to
> > do it.
>
>
> Actually this is not an issue.  I think we can release beta's as long as
> it is an officially voted on release.  It just signifies that new features
> are introduced before stabilizing or hardening the server.
>
> However this leads back to the main argument that the special unstable
> > build numbers are misleading when deployed to maven repos because the user
> > may not realize what the build number means and could use it in a production
> > app.
>
>
> Well the beta marker as you suggest does explicitly give a signal to the
> user.  I like it.
>
> I hate to spend so much time on this type of subject,
>
>
> This is very good tho - you're helping us answer some critical questions.
>
> but I just want to make sure that the users see things clearly and that we
> > don't impose any special rules on them with released versions.  The beta
> > solution may not be the prettiest, but there is a lot of precedent with
> > other projects and vendor products out there and at least this way the users
> > know exactly what they are getting when they download and install  ;-)  So
> > consider this just another suggestion...
>
>
> This is a good suggestion really.  Oh btw will this impose any issues with
> OSGi versioning?  Just thought I'd ask that.  Don't know what happens with
> the beta/alpha designators.
>
> Alex
>

Re: [Version Numbering scheme] was: Version numbering and roadmap planning

[Alex Karasulu <ak...@apache.org>]

Hiya Chris,

On 5/7/07, Chris Custine <ch...@gmail.com> wrote:
>
> My main concern with all of the implied meaning in the release numbers is
> that the users will not pay attention to it, and eventually get irritated
> with it when they have an issue with a new feature and we tell them that
> they probably shouldn't play with their shiny new toy in production.


Yeah true.  This is not a good situation to be in.

Last night it occured to me that maybe we have all overlooked an obvious
> solution that could make everyone happy.  With the unstable feature releases
> we are basically talking about a very formal beta testing phase.  So maybe
> we should call these releases beta releases, but without any special meaning
> embedded in the numbers.  So after a stable release of 1.6, why don't we
> do the typical release branch for bugfixe releases like 1.6.1, work off of
> the trunk for the next major release and do releases from trunk as 1.7beta 1,
> 1.7 beta 2, etc. until things are stable.  Or at least something along
> these lines.  I think this will make much more sense to the users and allows
> the Directory project to introduce new features in beta releases without
> worry of tripping up any bleeding edge users using beta releases.


I think I like this.  So the alpha would be for feature releases that may be
somewhat destabilized.  The beta would be for releases that are being
stabilized or optimized before a stable release?

What do others think?

There are a couple of small drawbacks.  Even though I see other projects
> doing it, we shouldn't release beta builds on the main maven repo, although
> I am not sure this is a hard rule, I think it is a general practice not to
> do it.


Actually this is not an issue.  I think we can release beta's as long as it
is an officially voted on release.  It just signifies that new features are
introduced before stabilizing or hardening the server.

However this leads back to the main argument that the special unstable build
> numbers are misleading when deployed to maven repos because the user may not
> realize what the build number means and could use it in a production app.


Well the beta marker as you suggest does explicitly give a signal to the
user.  I like it.

I hate to spend so much time on this type of subject,


This is very good tho - you're helping us answer some critical questions.

but I just want to make sure that the users see things clearly and that we
> don't impose any special rules on them with released versions.  The beta
> solution may not be the prettiest, but there is a lot of precedent with
> other projects and vendor products out there and at least this way the users
> know exactly what they are getting when they download and install  ;-)  So
> consider this just another suggestion...


This is a good suggestion really.  Oh btw will this impose any issues with
OSGi versioning?  Just thought I'd ask that.  Don't know what happens with
the beta/alpha designators.

Alex

Re: [Version Numbering scheme] was: Version numbering and roadmap planning

[Chris Custine <ch...@gmail.com>]

My main concern with all of the implied meaning in the release numbers is
that the users will not pay attention to it, and eventually get irritated
with it when they have an issue with a new feature and we tell them that
they probably shouldn't play with their shiny new toy in production.

Last night it occured to me that maybe we have all overlooked an obvious
solution that could make everyone happy.  With the unstable feature releases
we are basically talking about a very formal beta testing phase.  So maybe
we should call these releases beta releases, but without any special meaning
embedded in the numbers.  So after a stable release of 1.6, why don't we do
the typical release branch for bugfixe releases like 1.6.1, work off of the
trunk for the next major release and do releases from trunk as 1.7 beta 1,
1.7 beta 2, etc. until things are stable.  Or at least something along these
lines.  I think this will make much more sense to the users and allows the
Directory project to introduce new features in beta releases without worry
of tripping up any bleeding edge users using beta releases.

There are a couple of small drawbacks.  Even though I see other projects
doing it, we shouldn't release beta builds on the main maven repo, although
I am not sure this is a hard rule, I think it is a general practice not to
do it.  However this leads back to the main argument that the special
unstable build numbers are misleading when deployed to maven repos because
the user may not realize what the build number means and could use it in a
production app.

I hate to spend so much time on this type of subject, but I just want to
make sure that the users see things clearly and that we don't impose any
special rules on them with released versions.  The beta solution may not be
the prettiest, but there is a lot of precedent with other projects and
vendor products out there and at least this way the users know exactly what
they are getting when they download and install  ;-)  So consider this just
another suggestion...

Chris


On 5/7/07, Alex Karasulu <ak...@apache.org> wrote:
>
> Emmanuel,
>
> This 1.5, 2.5, 3.5 etc feature introduction branches along with 1.0, 2.0,
> 3.0
> for the stable bug fix branch is alright by me.  Really to me the goal is
> to
> be able to have a branch where only new features are introduced and
> another
> where we just make bug fixes.  New features can destabilize the server
> even
> though it has not yet.  This scheme is just the same to me as using the
> odd/even
> scheme.  Perhaps the odd/even scheme is a tiny bit more preferrable
> because
> people can relate to the Linux way to understand this.  However I really
> like this
> 1.5 schema because the message is a bit clearer that we're transitioning
> from
> one stable bug fix branch to the next.
>
> Effectively both are the same for me.
>
> However let me clarify why I personally like to have a feature release
> branch and
> a separate bug fix branch.
>
> 1. New features may destabilize the server
> 2. New features also may change interfaces
> 3. Feature branches buffer users from drastic compatibility changes like
> in the partition format
> 4. Also it's easier to track the generational differences between stable
> releases which simplifies
>     the maintenance, and the documentation.
>
> So this is why a feature release branch is a good idea for me.  However
> there are some
> disadvantages as well.
>
> 1. Users perceive the feature release branches as buggy when they are not
> necessarily unstable
> 2. Users have to wait longer for stable releases of the features they want
> and may not opt to use
>     releases from the unstable branch
>
> There may be more but perhaps others can add to both these lists with
> their own pros and cons.
>
> Alex
>
> On 5/7/07, Emmanuel Lecharny <el...@apache.org> wrote:
> >
> > Alan D. Cabrera a écrit :
> >
> > >
> > > 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!
> >
> > The key word is 'release'. We have had many discussion about what we
> > should call a release, and if we should have 'unstable' released at
> > all... Tags may be enough.
> >
> > But on the other side, Alex thinks that the stable/unstable scheme (à la
> > Linux) is a good thing.
> >
> > This is what we are trying to address, so this mail.
> >
> > Thanks Alan !
> >
> > >
> > >
> > > Regards,
> > > Alan
> > >
> > >
> >
> >
>

Re: [Version Numbering scheme] was: Version numbering and roadmap planning

[Alex Karasulu <ak...@apache.org>]

Emmanuel,

This 1.5, 2.5, 3.5 etc feature introduction branches along with 1.0, 2.0,
3.0
for the stable bug fix branch is alright by me.  Really to me the goal is to
be able to have a branch where only new features are introduced and another
where we just make bug fixes.  New features can destabilize the server even
though it has not yet.  This scheme is just the same to me as using the
odd/even
scheme.  Perhaps the odd/even scheme is a tiny bit more preferrable because
people can relate to the Linux way to understand this.  However I really
like this
1.5 schema because the message is a bit clearer that we're transitioning
from
one stable bug fix branch to the next.

Effectively both are the same for me.

However let me clarify why I personally like to have a feature release
branch and
a separate bug fix branch.

1. New features may destabilize the server
2. New features also may change interfaces
3. Feature branches buffer users from drastic compatibility changes like in
the partition format
4. Also it's easier to track the generational differences between stable
releases which simplifies
    the maintenance, and the documentation.

So this is why a feature release branch is a good idea for me.  However
there are some
disadvantages as well.

1. Users perceive the feature release branches as buggy when they are not
necessarily unstable
2. Users have to wait longer for stable releases of the features they want
and may not opt to use
    releases from the unstable branch

There may be more but perhaps others can add to both these lists with their
own pros and cons.

Alex

On 5/7/07, Emmanuel Lecharny <el...@apache.org> wrote:
>
> Alan D. Cabrera a écrit :
>
> >
> > 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!
>
> The key word is 'release'. We have had many discussion about what we
> should call a release, and if we should have 'unstable' released at
> all... Tags may be enough.
>
> But on the other side, Alex thinks that the stable/unstable scheme (à la
> Linux) is a good thing.
>
> This is what we are trying to address, so this mail.
>
> Thanks Alan !
>
> >
> >
> > Regards,
> > Alan
> >
> >
>
>

Re: [Version Numbering scheme] was: Version numbering and roadmap planning

[Emmanuel Lecharny <el...@apache.org>]

Alan D. Cabrera a écrit :

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

The key word is 'release'. We have had many discussion about what we 
should call a release, and if we should have 'unstable' released at 
all... Tags may be enough.

But on the other side, Alex thinks that the stable/unstable scheme (à la 
Linux) is a good thing.

This is what we are trying to address, so this mail.

Thanks Alan !

>
>
> Regards,
> Alan
>
>

Re: [Version Numbering scheme] was: Version numbering and roadmap planning

["Alan D. Cabrera" <li...@toolazydogs.com>]

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