On Mon, May 24, 2010 at 11:14 AM, Stefan Seelmann <seelmann@apache.org> wrote:
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.

Right I know what you mean. There's I guess no guarantee for stability although the product release may very well be stable with a milestone release.  The key thing here is how we want to formulate our contract with our users while we release and what cues we give them with our version numbering scheme.

You're right that this is not a major issue (bike shedding): either scheme will work.  I'm just in preference of simple numbers without designators. Let's release fast and release often and let the community know that minor releases in the same major release represents feature additions that don't break with the past.  Subsequent micro releases may patch and stabilize these features.
Anyway, I totally agree with all your other points. So let's go on.

Kind Regards,

Alex Karasulu wrote:
> On Sun, May 23, 2010 at 11:57 AM, Stefan Seelmann <seelmann@apache.org
> <mailto:seelmann@apache.org>> 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

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