Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4BFA3CCF.3040809@apache.org>
Date: Mon, 24 May 2010 10:46:07 +0200
From: Felix Knecht <felixk@apache.org>
Reply-To: felixk@apache.org
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.9) Gecko/20100509 Thunderbird/3.0.4
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [ApacheDS] Release versioning scheme.
References: <AANLkTikV6VcgKEoHYo5qg7Ddi8skWPov7SHjyCrCuwp9@mail.gmail.com>
	 <4BF8EDE9.9040004@apache.org>
 <AANLkTik26g2oTtImKqc7FB5Bz2raeMRWb7q0JKZyWRts@mail.gmail.com>
 <4BFA355A.4090308@apache.org>
In-Reply-To: <4BFA355A.4090308@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

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