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