directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [ApacheDS] Release versioning scheme.
Date Tue, 25 May 2010 04:29:12 GMT
On Mon, May 24, 2010 at 11:46 AM, Felix Knecht <felixk@apache.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/24/10 10:14, Stefan Seelmann 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.
> >
> > Anyway, I totally agree with all your other points. So let's go on.
>
>
> No matter which schema we use in the end, IMO we should choose a schema
> fitting the version number rules of maven [1].
>

Yeah I was thinking of this while I wrote my email and various OSGi tools
link bnd and their Maven Plugin.  I know there were some issues before but
they must have been resolved. Either way I just want to be super safe.

-Alex


>
> My 2 cents
> Felix
>
> [1] http://mojo.codehaus.org/versions-maven-plugin/version-rules.html
>
>
> >
> > Kind Regards,
> > Stefan
> >
> >
> > 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
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.15 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkv6PM8ACgkQ2lZVCB08qHEINACfalg/ibbued1W8wtGnE/ZKMJ5
> KA4Amwcb+JGwV8d+gSJJcTm4iwTngkmh
> =C1EQ
> -----END PGP SIGNATURE-----
>



-- 
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

Mime
View raw message