directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [ApacheDS] How about yet another versioning scheme conversation gang?
Date Tue, 11 Aug 2009 17:52:12 GMT
Martin Alderson wrote:
> 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.
2.2.6 -> 2.2.7 if this is a bug fix
2.2.6 -> 2.3.0 if it's a minor release
> 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 features (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 way for users
to get those bug fixes is to also get the latest new feature which might break backwards compatibility.
We can maintain older versions too, but I would say it's a matter of 
having volunteers ready to do that.
> If you are going to maintain a separate branch just for bug fixes is that just for the
0 minor version i.e. 2.0.X like it is now?  So people who are on 2.1.X will have to upgrade
to 2.2.X etc to keep up with the big fixes?
Once a tag is created, branches start at this tag. Ie, if we release 
2.2.0, then trunk will be for 2.3.0 and 2.2.1 will be the bug fix for 
the tagged version 2.2.6. We can also maintain a 2.1.14 version, if needed.
> When you release ApacheDS 3 do you abandon ApacheDS 2 so users must upgrade to take advantage
of the latest bug fixes? 
Not necessarily. But likely, unless some people are willing to maintain 
it. Httpd 1.3 is still maintained, but not heavily.
> I think it is very important for any changes that require the user to do something other
than just upgrade be well labelled and avoidable without compromising the security or stability
of the server.  For that I think you need at least two main branches as you have now (1.0.X
and 1.5.X), one for serious bug fixes and one for new backwards compatibility breaking functionality.
When 2.0.0 will be released, we will consider 1.0 as dead wood. That 
means we won't add any feature to this branch. When 3.0.0 will be 
release, 2.0.0 will be a bug fix only branch. And so on.
> The question is what to do with the other changes that don't break backwards compatibility
and aren't security / stability fixes.  Assuming we don't want to maintain more than 2 branches
these changes need to be grouped with one of them. 
> Apologies if that all came across a bit muddled or unfinished - gotta run!
> Martin

cordialement, regards,
Emmanuel L├ęcharny

View raw message