On Sun, May 23, 2010 at 11:57 AM, Stefan Seelmann <email@example.com>
Alex Karasulu wrote:No sure about that, httpd released a 2.3.5-alpha
> 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
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 fixI think milestones can be used to indicate that we are on the way to
> 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.
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
- 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