directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Versioning scheme
Date Sun, 29 Oct 2006 18:11:21 GMT
Trustin Lee wrote:
> On 10/29/06, *Alex Karasulu* <aok123@bellsouth.net 
> <mailto:aok123@bellsouth.net>> wrote:
> 
>     I tried to sum up some of the recent conversations here:
> 
>     http://cwiki.apache.org/confluence/display/directory/Version+Numbering+Scheme
>     <http://cwiki.apache.org/confluence/display/directory/Version+Numbering+Scheme>
> 
>     If I messed anything up please correct me.
> 
> 
> "Some consider bumping the minor number several notches from say a 1.0 
> to a 1.5 for example to connotate a change in platform like switching 
> from JDK 1.4 to JDK 5.0. This is also an acceptable tactic to employ."
> 
> I would rather start from 2.1 than from 1.5 because it shows that it has 
> a big change more clearly.  But we lose 2.0. That's why I talked about 
> switching the meaning of even and odd. :)

I really liked that switch it was a great idea but we already have 1.0 
as stable and switching our semantics now is going to create a confusing 
situation.

> 
> "Minor numbers are used to connotate changes to features and APIs in the 
> product with minor changes which may or may not introduce compatibility 
> issues."
> 
> 'May or may not' sounds too ambiguous.  Could you clarify it?

It's a matter of degree is all I am saying.  Let me elaborate  ...

Say you changed a couple things in the MINA API in the 1.1 branch. 
These changes break a few things in terms of compatibility.  Say a few 
method signatures changed.  This IMHO is not a big deal for users to 
have to deal with, especially if the API is getting better.  But it does 
break compatibility with 1.0 since users cannot seemlessly swap jars 
from 1.0.x and 1.1.x right?

But the degree of breakage is negligible and will not require someone to 
re-implement their application.  At most a few lines of code will change 
to adjust and things need to be recompiled.

However you might be a bit more conservative and require the API to 
preserve backwards compatibility such that only new additions are being 
made with consecutive minor number jumps.

My use of "may or may not" was to give us some flexibility on what we 
consider to be minor version changes.

Now if you drastically alter MINA's API for example and the principals 
behind it change in 1.1.x users may have to rewrite major portions of 
their application using MINA.  This is not a good practice IMO.  You 
probably should jump past a few minor versions or jump to a new major 
version.

Does this clarify my things more?

Alex




Mime
View raw message