directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [ApacheDS] Release versioning scheme.
Date Sun, 23 May 2010 12:07:37 GMT
On Sun, May 23, 2010 at 11:57 AM, Stefan Seelmann <>wrote:

> Alex Karasulu wrote:
> > Yes this scheme is much more appealing. However I'm not into this
> > milestone designation. I don't really see the point (perhaps someone
> > might show me in this thread). Let me explain my thinking below.
> >
> > To me you either have a release or you don't release. With the httpd
> > scheme above you have no need for milestone releases because 2.0.0,
> > 2.1.0, 2.2.0 ... X.Y.0 are milestones in that they introduce new
> No sure about that, httpd released a 2.3.5-alpha
Hmmm OK I didn't know that. Regardless though I think the designation is
unnecessary. The new minor release number inherently represents something
that has changed by adding new features which may destabilize the software.
We don't really know how much and if that amount means give it an alpha
flag. How alpha is alpha?

Plus with certain tooling this -alpha designator might be an issue. Why
bother dealing with the risk?

> > features.  Hence the minor bump.  The micro releases are just bug fix
> > releases that do not introduce new features after the minor
> > ("milestone") release. So this is why this httpd scheme does not need
> > M1, M2 .. a la eclipse style releases.
> I think milestones can be used to indicate that we are on the way to
> 2.0, but it's not ready yet.
I'm still not convinced of this technique. I know eclipse uses this but it's
not very appealing to me. I prefer the new Linux kernel scheme which fits
what I spoke of in the block above.

> As Emmanuel wrote, we have several tasks to do:
> - documentation of the new features
> - update the current documentation
> - update the examples
> - tooling
> - bug fixing
> - renew Open Group certification?
> I'm in doubt we can do this within 3 weeks.
Well no matter how long that might take people can still build the server if
they like and we should have nightly builds available for testing between
these periods. I was a +1 on the switch from doing 1.5.x builds to starting
to bring forth a 2.0.

> An M1 could indicate to our users: hey, ApacheDS now supports RFC 4533
> replication and CiDIT. Help to test it. Test interoperability with
> OpenLDAP. Provide feedback.
I think we should just release the 2.0.0 in 3 weeks and let people go wild
with it.

> And for us it indicates: no more big-bang refactoring till 2.0 GA, but
> we can still modify API during bug fixing.
The same fits for a 2.0.1 ... 2.0.*. I think we should keep things simple
here. Just because some projects use this M* scheme that does not mean we
should too.

> > The next thing we need to talk about is what the major, minor and mico
> > releases signify to our users.  Here's how I look at it in terms of our
> > user agreement:
> >
> >   o major releases do not guarantee interoperability out of the box
> > since internal and external interfaces, db formats, and the entire
> > architecture may change
> >   o minor releases guarantee interoperability, interface integrity, db
> > format consistency across releases with architectural stability. New
> > features may be introduced and some features may be enhanced.
> >   o micro releases are simple bug fix releases which do not introduce
> > anything new
> +1
> Kind Regards,
> Stefan

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message