Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
From: Martin Alderson <Martin.Alderson@salfordsoftware.co.uk>
To: Apache Directory Developers List <dev@directory.apache.org>
Date: Tue, 11 Aug 2009 18:37:04 +0100
Subject: RE: [ApacheDS] How about yet another versioning scheme conversation
 gang?
Thread-Topic: [ApacheDS] How about yet another versioning scheme
 conversation gang?
Thread-Index: AcoahGhHdoOTZNTXQQ6XvJEKQ0ZY9QAIYO8Q
Message-ID: <5A2110DC1CD00B45A0832E5BF98ECB060E75BBCE73@ex2>
References: <a32f6b020908110604s393415a2t48b993a77b2ba0f@mail.gmail.com>
In-Reply-To: <a32f6b020908110604s393415a2t48b993a77b2ba0f@mail.gmail.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi guys,

To clarify, do we go from e.g. 2.2.6 to 2.3.0, 2.3.6 or 2.3.7?  It doesn't =
really matter but I just wanted to make sure I understand.

Some thoughts...

Is the minor number just there to indicate to users that shiny new features=
 have been added to ApacheDS?  Does it give them a way to avoid those new f=
eatures (i.e. if the user is only interested in bug fixes)?

If bug fixes are only released for the latest minor version then the only w=
ay for users to get those bug fixes is to also get the latest new feature w=
hich might break backwards compatibility.

If you are going to maintain a separate branch just for bug fixes is that j=
ust for the 0 minor version i.e. 2.0.X like it is now?  So people who are o=
n 2.1.X will have to upgrade to 2.2.X etc to keep up with the big fixes?

When you release ApacheDS 3 do you abandon ApacheDS 2 so users must upgrade=
 to take advantage of the latest bug fixes?=20

I think it is very important for any changes that require the user to do so=
mething other than just upgrade be well labelled and avoidable without comp=
romising the security or stability of the server.  For that I think you nee=
d at least two main branches as you have now (1.0.X and 1.5.X), one for ser=
ious bug fixes and one for new backwards compatibility breaking functionali=
ty.

The question is what to do with the other changes that don't break backward=
s compatibility and aren't security / stability fixes.  Assuming we don't w=
ant to maintain more than 2 branches these changes need to be grouped with =
one of them.=20

Apologies if that all came across a bit muddled or unfinished - gotta run!

Martin