Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 9993 invoked from network); 7 May 2007 12:34:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 May 2007 12:34:09 -0000 Received: (qmail 88908 invoked by uid 500); 7 May 2007 12:34:15 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 88850 invoked by uid 500); 7 May 2007 12:34:15 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 88839 invoked by uid 99); 7 May 2007 12:34:15 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 May 2007 05:34:15 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of akarasulu@gmail.com designates 66.249.92.171 as permitted sender) Received: from [66.249.92.171] (HELO ug-out-1314.google.com) (66.249.92.171) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 May 2007 05:34:07 -0700 Received: by ug-out-1314.google.com with SMTP id 71so899807ugh for ; Mon, 07 May 2007 05:33:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=o2hQ6A9WV5aBcwhEdnxDBKcIwgkVR5odrf8e9IIy9grFUKyoN3QuHZ4L5oNtA2j7GVhWFc5Z4S5nE+ErfR2oTcpnJJgIyBydzR/iaWXqYzwE+IS2ivxCd+h/2S1DhmtZd0WDV/iORMBe8wSInqd8O1nYWmgl8xGQSgABPAfVLgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=c50iOOO3SoK5jpuTDVBLgexEIuH3Dp9ArvqH98YCWuJZcjpyRi1XxGkVFmWQKb6xhi6DkhWEQ/ORsF2xMmJZeRMRBPTII30Tm/VKibxuK8bGpnsUSLC03lPvwKdW3dyKFrrjrgjoOatzs22TaNyp7Jo5ObyiQhBR6IewyuWTY4k= Received: by 10.67.121.18 with SMTP id y18mr942649ugm.1178541225929; Mon, 07 May 2007 05:33:45 -0700 (PDT) Received: by 10.67.69.15 with HTTP; Mon, 7 May 2007 05:33:45 -0700 (PDT) Message-ID: Date: Mon, 7 May 2007 08:33:45 -0400 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" Subject: Re: [Version Numbering scheme] was: Version numbering and roadmap planning In-Reply-To: <463EC88B.8010005@apache.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_76139_9356202.1178541225823" References: <43b026c70705031756j6107732eo24ecb9e05c55507c@mail.gmail.com> <463C7607.3050902@apache.org> <463EC88B.8010005@apache.org> X-Google-Sender-Auth: c4271bea6f12f74e X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_76139_9356202.1178541225823 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 t= o 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 wrote: > > Alan D. Cabrera a =E9crit : > > > > > 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 !=3D buggy, but unstable =3D=3D experimen= tal) > >> > >> 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=3D0, or for new features or bug fixes > if Y=3D5. > >> > >> 1.5.2 =3D> new features has been added to 1.5.1 > >> 2.0.3 =3D> 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 (=E0 l= a > Linux) is a good thing. > > This is what we are trying to address, so this mail. > > Thanks Alan ! > > > > > > > Regards, > > Alan > > > > > > ------=_Part_76139_9356202.1178541225823 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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.&nbs= p; Really to me the goal is to
be able to have a branch where only new f= eatures are introduced and another
where we just make bug fixes.  New features can destabilize the se= rver even
though it has not yet.  This scheme is just the same to m= e as using the odd/even
scheme.  Perhaps the odd/even scheme is a t= iny 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 w= e'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 bu= g 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 lik= e in the partition format
4. Also it's easier to track the generatio= nal differences between stable releases which simplifies
  &n= bsp; 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 perceiv= e the feature release branches as buggy when they are not necessarily unsta= ble
2. Users have to wait longer for stable releases of the features they w= ant and may not opt to use
    releases from the unstable bran= ch

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 <elecharny@apache.org> wrote:
Alan D. Cabrera a =E9crit :

>
> On May 5, 2007, at 5:18 AM,= Emmanuel Lecharny wrote:
>
>> Ok, I agree with a lot of Chr= is 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&n= bsp; think
>> that Alex is right when it comes to have stable= /unstable  revisions
>> (keep in mind that unstable !=3D= buggy, but unstable =3D=3D  experimental)
>>
>> We have had a convo with Alex this morning while w= e 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 bu= g, 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 s= table, and feature completed. If 5,
>> then this is an intermediate version
>> Z : used for = bug fixes if Y=3D0, or for new features or bug fixes if  Y=3D5.>>
>> 1.5.2 =3D> new features has been added to 1.5.1>> 2.0.3 =3D> stable version 2, with third delivered set of bug fixes.
>&g= t;
>> wdyt ?
>
>
>
> This all sounds a bit= abstract to me.  Can you provide some concrete
> uses case= s 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 weshould call a release, and if we should have 'unstable' released = at
all... Tags may be enough.

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

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

Thanks Alan !

>
>
> Regards,
> Alan
>
>


------=_Part_76139_9356202.1178541225823--