Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 69507 invoked from network); 11 Aug 2009 13:54:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Aug 2009 13:54:37 -0000 Received: (qmail 26149 invoked by uid 500); 11 Aug 2009 13:54:44 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 26099 invoked by uid 500); 11 Aug 2009 13:54:44 -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 26091 invoked by uid 99); 11 Aug 2009 13:54:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Aug 2009 13:54:44 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 209.85.210.180 as permitted sender) Received: from [209.85.210.180] (HELO mail-yx0-f180.google.com) (209.85.210.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Aug 2009 13:54:34 +0000 Received: by yxe10 with SMTP id 10so4385729yxe.15 for ; Tue, 11 Aug 2009 06:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=pFrX0/SZqtqHC8TYCyKgiHCmO4p5bssLjKpmSQzyNcQ=; b=ZtX4OFUQ/h9wxgnUyQowS3Mj1aak2QIleUpvTNkllFPpksO55CzYgvUJSa7SUp9sQF KpxX1Wdtwib/3Vb16hEfHm7UGc+dj8tNhWpveYEwBZIjWD0pjDNHL/TaunreEKhEuIDT +cysJPWof4TFiTpJ7k6Zrv7nauy6RhkWu4+zY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=J3TUP0rHgbpsPNBPQBc2fUSI/4LjQySA4iXDkNDXuuKZ1U8gYNOq2oTz/p9XFScber M67OIQGY56Hg4KpBlYg78AU3cEyKu4VnisV8I4ORSQoedGgVbmSwwfCAuiOQBsozTbxx pTIaLM9VuBbdu/dkBHruks0RK966N1XhbDMjU= MIME-Version: 1.0 Received: by 10.100.13.14 with SMTP id 14mr5394024anm.51.1249998853556; Tue, 11 Aug 2009 06:54:13 -0700 (PDT) In-Reply-To: <4A817360.2030406@nextury.com> References: <4A817360.2030406@nextury.com> Date: Tue, 11 Aug 2009 16:54:13 +0300 Message-ID: Subject: Re: [ApacheDS] How about yet another versioning scheme conversation gang? From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=0016e644de96a2ce1b0470de09b9 X-Virus-Checked: Checked by ClamAV on apache.org --0016e644de96a2ce1b0470de09b9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think we're on the same page. But I would add one more caveat, that Y "tries" to maintain API compatibility but there is no guarantee. Z is what only guarantees API compatibility. Thanks guys for the feedback. I guess we should just go with this unless anyone has any objections until release time. Regards, Alex On Tue, Aug 11, 2009 at 4:34 PM, Emmanuel Lecharny wr= ote: > Jesse McConnell wrote: > >> o We have major.minor.micro numbers: >>> - major number denotes massive architectural shift >>> - minor number denotes feature introductions >>> - micro number denotes bug fixes and optimizations without changes t= o >>> interfaces, db formats etc >>> >>> >> >> Why not just adopt the convention that people most commonly associate >> with x.y.z? >> >> X - breaks API, no assurance that you can use out of the box >> Y - features api alteration but basic assurance of api compat >> Z - bug fixes and maintenance releases >> >> > I don't think it's far from Alex proposal. As we don't have that much API > exposed, we can say that Y also means the API is not broken. That probabl= y > will imply some @deprecated annotation, nothing much > > I don't see a need to do anything else unless your dealing with some >> requirement being forced on you >> >> > Nothing can force us ;) > >> fwiw your new one is far more inline with that basic idea and is much >> better then your previous one dealing with .0 and .5 and that >> confusion... >> >> > This .5 stuff was introduced just as we wanted to move to Java 5, =E0 la > Tomcat (remember the 5.0/5.5 versions. Looking back in anger, it was not > really a good idea... > > So basically, +1 for Alex proposal, assuming Jesse proposal fits in it. > > -- > -- > cordialement, regards, > Emmanuel L=E9charny > www.iktek.com > directory.apache.org > > > --=20 Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org --0016e644de96a2ce1b0470de09b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think we're on the same page.=A0 But I would add one more caveat, tha= t Y "tries" to maintain API compatibility but there is no guarant= ee.=A0 Z is what only guarantees API compatibility.

Thanks guys for= the feedback.=A0 I guess we should just go with this unless anyone has any= objections until release time.

Regards,
Alex

On Tue, Aug 11, 2009= at 4:34 PM, Emmanuel Lecharny <elecharny@apache.org> wrote:
Jesse McConnell wrote:
=A0o We have major.minor.micro numbers:
=A0 =A0- major number denotes massive architectural shift
=A0 =A0- minor number denotes feature introductions
=A0 =A0- micro number denotes bug fixes and optimizations without changes = to interfaces, db formats etc
=A0 =A0

Why not just adopt the convention that people most commonly associate
with x.y.z?

X - breaks API, no assurance that you can use out of the box
Y - features api alteration but basic assurance of api compat
Z - bug fixes and maintenance releases
=A0
I don't think it's far from Alex proposal. As we don't have tha= t much API exposed, we can say that Y also means the API is not broken. Tha= t probably will imply some @deprecated annotation, nothing much


I don't see a need to do anything else unless your dealing with some requirement being forced on you
=A0
Nothing can force us ;)

fwiw your new one is far more inline with that basic idea and is much
better then your previous one dealing with .0 and .5 and that
confusion...
=A0
This .5 stuff was introduced just as we wanted to move to Java 5, =E0 la To= mcat (remember the 5.0/5.5 versions. Looking back in anger, it was not real= ly a good idea...

So basically, +1 for Alex proposal, assuming Jesse proposal fits in it.

--
--
cordialement, regards,
Emmanuel L=E9charny
www.iktek.com
directory.apache.= org





--
Alex KarasuluMy Blog :: http://www.jrolle= r.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org

--0016e644de96a2ce1b0470de09b9--