Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 84976 invoked from network); 29 Oct 2006 06:36:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Oct 2006 06:36:26 -0000 Received: (qmail 4961 invoked by uid 500); 29 Oct 2006 06:36:36 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 4920 invoked by uid 500); 29 Oct 2006 06:36:36 -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 4909 invoked by uid 99); 29 Oct 2006 06:36:36 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Oct 2006 23:36:36 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of ersin.er@gmail.com designates 64.233.162.207 as permitted sender) Received: from [64.233.162.207] (HELO nz-out-0102.google.com) (64.233.162.207) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Oct 2006 23:36:24 -0700 Received: by nz-out-0102.google.com with SMTP id z3so865167nzf for ; Sat, 28 Oct 2006 23:36:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=l2TG2+GXs6UEb4g6nd/5HutcxmBr8kmPW0SXRHVqw4qpgqP8FYnjA4yi8XHXu9LO9Mbnb1iIl9LV9T0JoxOeufC9shw/rOYECKbe4sthOcmROHRjqoRAzvrejgQVPjKJRr9OYeCkafJsYQ+PaiKP0oy0WkMiCcvBrPYZTN8nIfM= Received: by 10.35.14.1 with SMTP id r1mr1982543pyi; Sat, 28 Oct 2006 23:36:03 -0700 (PDT) Received: by 10.35.127.12 with HTTP; Sat, 28 Oct 2006 23:36:03 -0700 (PDT) Message-ID: Date: Sun, 29 Oct 2006 08:36:03 +0200 From: "Ersin Er" To: "Apache Directory Developers List" Subject: Re: Sum-up: Versioning Scheme In-Reply-To: <768dcb2e0610281800h63d8897cgeb8516bf4733c5e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <768dcb2e0610281800h63d8897cgeb8516bf4733c5e@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org [OT] On 10/29/06, Trustin Lee wrote: > Hi all, > > The previous thread on versioning scheme is becoming very long, so I want to > split it into two by summarizing what we agreed on. Alex summarized our > current versioning scheme here: > > http://cwiki.apache.org/confluence/display/directory/Version+Numbering+Scheme I have moved the page to: http://cwiki.apache.org/confluence/display/DIRxPMGT/Version+Numbering+Scheme Seemed to be a better place to live for that document. And a very important thing is that "We must always give the URLs from wiki through the autoexported pages which will be something like: http://cwiki.apache.org/DIRxPMGT/Version+Numbering+Scheme This is important to keep the Confluence instance alive. However the autoexport plugin for Confluence currently does not as intended due to incompatibility problems with the latest Confluence version. So we do not have static pages for some of out already edited spaces. I hope all will be fine soon. > I agree with his idea mostly, but there are two points to raise: > > 1. 1.5 -> 2.0 vs 1.9 -> 2.0 vs 2.1 -> 2.2 > > 1.5 is a very arbitrary number and this rule cannot be applied to the future > similar changes. What happens if we move to Java 6? What happens we > already released 1.7 and if we move to Java 7? 1.9 has also a similar > problem; what happens if we already released 1.8? There's no way to > distinguish from previous releases because we are out of bullet. > > 2.1 -> 2.2 also has a problem that 2.0 will never be released, which is kind > of weird. Releasing 2.0-M1/2/3/4...and then RC1/2/3... and finally 2.0 can > be a solution, but it makes the even/odd scheme pointless because we can > just use 'M{number}' to state that it's unstable. Of course, we can start > over with this whole new scheme. > > 2. Clarify the meaning of minor version number. > > 'may or may not' sounds very ambiguous. We need to clarify it. > > We can just go 1.5 or 1.9 not settling down the version numbering scheme, > but we will encounter the same problem on and on. I'm not a perfectionist, > but I want to set up a nice rule that can be applied for as many cases as we > can cover. Now the thread is hot, it's a great time to gather all opinions > and to improve our version numbering scheme. > > Trustin > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP key fingerprints: > * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E > * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6 -- Ersin