From dev-return-36372-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed Jan 05 20:25:56 2011 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 68553 invoked from network); 5 Jan 2011 20:25:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Jan 2011 20:25:56 -0000 Received: (qmail 24845 invoked by uid 500); 5 Jan 2011 20:25:56 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 24717 invoked by uid 500); 5 Jan 2011 20:25:56 -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 24710 invoked by uid 99); 5 Jan 2011 20:25:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jan 2011 20:25:56 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 209.85.216.178 as permitted sender) Received: from [209.85.216.178] (HELO mail-qy0-f178.google.com) (209.85.216.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jan 2011 20:25:49 +0000 Received: by qyk33 with SMTP id 33so16096767qyk.16 for ; Wed, 05 Jan 2011 12:25:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=X2Zu77+Ywhaqj/OJFSuA9iV8SNpYi4Y/X1XZb87aYU4=; b=ovuzQnhrH8EnH81dHTJR5tB4ycJCaiv0GXLncx9Nre6hqYznMZAhZBM9K7pMF7x9Uy MKoeh6FUHEces+J8NGaiNmH0At8g3s0Pvee2LBgplQcml0n6/0kXKEKr5ITVJElLbfMA KotN9WotrLPDx/kV0twHzHcgOd//4i8mSKqVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=mN+3LhLVIJERKWALroiAA8YzJbMN0OYKKqvP+/8muqmonSgAdPt1wxf4LrWx/hUcvZ ePfzz1eBL619aI0offkJj0r0YHCEvs2KVWNjtB1Aw7HuWdNpDWSPI95TwPlcOGLqvegb B0IVOsE7bjSZGIARk/Z/363rwJ93bo21jOp1g= MIME-Version: 1.0 Received: by 10.229.28.143 with SMTP id m15mr20463719qcc.162.1294259126478; Wed, 05 Jan 2011 12:25:26 -0800 (PST) Sender: akarasulu@gmail.com Received: by 10.229.63.23 with HTTP; Wed, 5 Jan 2011 12:25:26 -0800 (PST) In-Reply-To: <4D24D16C.4010803@gmail.com> References: <4D24D16C.4010803@gmail.com> Date: Wed, 5 Jan 2011 22:25:26 +0200 X-Google-Sender-Auth: _kBeZ9tGpIQE-8zmgcLl7S6YQsE Message-ID: Subject: Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases From: Alex Karasulu To: Apache Directory Developers List , elecharny@apache.org Content-Type: multipart/alternative; boundary=0016363b95967b26c404991f2f2b X-Virus-Checked: Checked by ClamAV on apache.org --0016363b95967b26c404991f2f2b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 5, 2011 at 10:15 PM, Emmanuel Lecharny wrote: > On 1/5/11 8:08 PM, Alex Karasulu wrote: > >> On Wed, Jan 5, 2011 at 8:06 PM, Jesse McConnell >> wrote: >> >> 1. Milestone Scheme (Eclipse) >>> >>> to further explain that one, those are just the public versions that >>> people consume...under the hood all of the bundles follow the osgi >>> versioning convention of major.minor.bugfix.qualifier so it looks like >>> 7.2.2.v20101205 or some variation there of. >>> >>> >>> I like this a lot. This way there's a product release version yet all >> component bundles can be versioned separately. This way their releases can >> occur independently of the product to allow for updates. >> >> This sounds more granular to me. Different component bundles will change >> at >> different rates and to allow this in a manageable way is wonderful. >> > +1 too. I'm not convinced about the need to have those v stuff, but > it does not cost anything, so I buy it. > > +1 > > if you guys are targeting osgi at any point then I would recommend you >>> just stick with that scheme, similar to how we do versioning in jetty >>> which works pretty well. >>> >> >> OSGi is something we've been considering for the past 7 years :-). However >> it's definitely not something we're going to do for the 2.0 server >> release. >> > If we go for miletsones (ie 2.0-Mx), then I have no problem to try to get > OSGi injected. It may postpone the 2.0-GA release, but frankly, I don't > think it will cost a lot. Add to this that many OSGi aware peeps are ready > to give an hands here. > > +1 then let's just do a 2.0-M1 release. This is great and gets users used to the new scheme. Plus we can modify the API without flipping out - the contract is clear to users, things will change. And you get the 2.0 advancing feeling that might help get more adoption into the picture. I'm liking this a lot! > building with maven the -SNAPSHOT is turned into the qualifier so we >>> just go with 7.3.0-SNAPSHOT and so on til a release and then we go >>> with v'year'month'day...we use the v so that it sorts correct with >>> things like 7.3.0.RC0, etc.. >>> >>> Thanks for the input. For the record I too think #1 is the best option >> for >> us going forward. >> > > Question : how do we propagate the 7.3.0-xxyz versions ? Right now, > releasing is a damn complex process which costs us one week (well, let's say > 4 days if everything goes fine, vote included). > > Or is this just equivalent to a nightly build ? I really have to read this eclipse link you put up. I've never released the Eclipse way. Off the cuff with common sense I am thinking we have for example 2.0.0-M1-cmajor.cminor.cmicro for each component where the, cmajor = component major version, cminor = component minor version, and cmicro = component micro version Adjusting this in our build is easy I think. We can play with it down the line if the others agree with this new scheme. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu --0016363b95967b26c404991f2f2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 5, 2011 at 10:15 PM, Emmanuel Lechar= ny <elecharny@g= mail.com> wrote:
On 1/5/11 8:08 PM, Alex Karasulu wrote:
On Wed, Jan 5, 2011 at 8:06 PM, Jesse McConnell
<jesse.mc= connell@gmail.com>wrote:

1. Milestone Scheme (Eclipse)

to further explain that one, those are just the public versions that
people consume...under the hood all of the bundles follow the osgi
versioning convention of major.minor.bugfix.qualifier so it looks like
7.2.2.v20101205 or some variation there of.


I like this a lot. This way there's a product release version yet all component bundles can be versioned separately. This way their releases can<= br> occur independently of the product to allow for updates.

This sounds more granular to me. Different component bundles will change at=
different rates and to allow this in a manageable way is wonderful.
+1 too. I'm not convinced about the need to have those v<Date> st= uff, but it does not cost anything, so I buy it.


+1
=A0

if you guys are targeting osgi at any point then I would recommend you
just stick with that scheme, similar to how we do versioning in jetty
which works pretty well.

OSGi is something we've been considering for the past 7 years :-). Howe= ver
it's definitely not something we're going to do for the 2.0 server = release.
If we go for miletsones (ie 2.0-Mx), then I have no problem to try to get O= SGi injected. It may postpone the 2.0-GA release, but frankly, I don't = think it will cost a lot. Add to this that many OSGi aware peeps are ready = to give an hands here.


+1 then let= 9;s just do a 2.0-M1 release. This is great and gets users used to the new = scheme. Plus we can modify the API without flipping out - the contract is c= lear to users, things will change. And you get the 2.0 advancing feeling th= at might help get more adoption into the picture.

I'm liking this a lot!=A0
=A0
building with maven the -SNAPSHOT is turned into the qualifier so we
just go with 7.3.0-SNAPSHOT and so on til a release and then we go
with v'year'month'day...we use the v so that it sorts correct w= ith
things like 7.3.0.RC0, etc..

Thanks for the input. For the record I too think #1 is the best option for<= br> us going forward.

Question : how do we propagate the 7.3.0-xxyz versions ? Right now, releasi= ng is a damn complex process which costs us one week (well, let's say 4= days if everything goes fine, vote included).

Or is this just equivalent to a nightly build ?

=
I really have to read this eclipse link you put up. I've nev= er released the Eclipse way.=A0

Off the cuff with = common sense I am thinking we have for example 2.0.0-M1-cmajor.cminor.cmicr= o for each component where the,

=A0=A0 =A0cmajor =3D component major version,=A0
<= div>=A0=A0 =A0cminor =3D component minor version, and=A0
=A0=A0 = =A0cmicro =3D component micro version

Adjusting th= is in our build is easy I think. We can play with it down the line if the o= thers agree with this new scheme.

--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server = :: http://directory.apache.org<= br> Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
--0016363b95967b26c404991f2f2b--