directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Versioning scheme
Date Sat, 28 Oct 2006 14:36:16 GMT
Trustin Lee a écrit :

> On 10/28/06, Emmanuel Lecharny <> wrote:
>> IMHO, switching to Java 5 deserve a special number, and to follow what
>> has been done by tomcat team, it seems to be a good idea to switch to
>> 1.5, just to be able to tell : "the current version is using Java 5".
> Do we move to 1.6 or 2.6 when we move to Java 6?

Good question :)
I think it will be something like 2.0 or 3.0 ...

(grrr... why the hell sun is now pushing a new Java version every 6 
months ? ;)

> An question could be : "will mina+java5 be stable or not?". If the
>> answer is "yes", then you should use 2.0 instead of 1.5. Major versions
>> are supposed to bring huge refactoring, with potentially API breakage
>> and modification. If you are using java 5, this will likely be the case,
>> except if you decide to use Java 5 just to get rid of backported code.
> That 2.0 *can't* be 'stable' but our versioning scheme says its stable.
> That's the point of my idea.

but do you think that 1.0 is stable ?

At this point, stability means : "no more API modification", not "no 
more bug" ;)

> So, to gather my opinion, here is what I think :
>> - If you want to switch to Java 5 with no change in the API, in order to
>> get rid of backported code, then 1.5 is the number
> We won't do this.  Anyway, Alex told me that the change of the platform
> means increasing major version number.  WDYT, Alex?

It's up to you, as mina is a TLP. For ADS, there  won't be difficult to 
manage, as we will just point to a version, so it's fine.

The vote on ADS for Java 5 switching was much more a question of using 
java 5 for new dev, without having to wait for a 2.0. Man, there are not 
one simple and perfect solution, everything is just either light or dark 
gray :)

> - If you want to use Java 5 features, like enum, generics, concurrence,
>> then it should be a 2.0
> Again, 2.0 means 'stable' from '0', but it can't be stable because it 
> is the
> first release in the new major version number.

No, stable does not mean "no bugs". It means, "features complete", so 
this is ok.

> Btw, I think that 1.1, 1.2, etc ... should not change the 1.0 API. If I
>> check out the trunk, I can see that some classes have been deleted, and
>> some methods have been changed. Please use "deprecated" tag, this is
>> exactly what it is good for. If you need to change the existing API,
>> then do it in a 2.0 trunk, not in a 1.x trunk. It will be more and more
>> important as many people will use Mina...
> It's not what we have been doing so far and we didn't create our initial
> versioning scheme to work in the manner you are saying.  For example, 
> 1.2and
> 1.3 can have very different API and feature set.  But 1.2 and 1.2.1 will
> have the same API and the same features.  Of course, if the API design 
> is so
> great, then 1.2 and 1.4 will have the same API but different features.

Even if you do that, for compatibility issues, you should deprecate and 
not remove, unless impossible. Adding new features is OK, as soon as the 
API remains consistant for a major version. deprecating a method from a 
"x.y.t" to a "x.y.z" is not an option, as the last digit is for bug 
fixes. So in my mind, when changing something in a minor version imply 
that you deprecate the previous API modified elements.

Of course, this is something that is questionnable, but at least, we 
should define what is what, and stick to it, and inform users !

> Trustin


View raw message