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)?
yes.
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
www.iktek.com
directory.apache.org
