Hi Alex, I don't insist on those milestone releases. I just find them useful in this case to be able to release fast, even if not everything is finished, and to avoid that users think everything is polished.
Anyway, I totally agree with all your other points. So let's go on. Kind Regards, Stefan Alex Karasulu wrote: > > > On Sun, May 23, 2010 at 11:57 AM, Stefan Seelmann <[email protected] > <mailto:[email protected]>> 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 :: http://www.jroller.com/akarasulu/ > Apache Directory Server :: http://directory.apache.org > Apache MINA :: http://mina.apache.org > To set up a meeting with me: http://tungle.me/AlexKarasulu
