mina-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 Sat, 28 Oct 2006 17:38:38 GMT
Trustin Lee wrote:
> On 10/28/06, *Emmanuel Lecharny* <elecharny@gmail.com 
> <mailto:elecharny@gmail.com>> 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?

Hehe I see what you mean.  However I think moving from 1.0 to 1.5 was 
more arbitrary.  We could have jumped from 1.0 to 1.23 etc.

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

I hear you and this is a problem with our scheme but I think there are 
viable alternatives (workarounds).  I explain some of them down below.

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

Hmmm sorry I don't know who is we in this context?

Anyway, Alex told me that the change of the platform
> means increasing major version number.  WDYT, Alex?

Really I think both are viable however the option depends on your 
circumstances.  The key here is to send a audible message to the user 
that something big has changed right?

When the user starts shopping for MINA/ApacheDS upgrades they'll see the 
big jump from 1.0 -> 1.5 or from 1.0 -> 2.0 and that big jump will mean 
something to them.  However there are subtle differences between the 
jump from 1.0 -> 1.5 and the 1.0 -> 2.0 jumps.  I think the decision to 
where to jump from 1.0 with a change in the JDK is up the perceived 
stability of the product and your intension for introducing more 
features right after this change.  Let me explain ...

Say you want to make this jump to JDK 5 for MINA and discontinue support 
for JDK 1.4.  However right after you do that, you don't want to 
introduce new features right away but just release a stable product.  So 
if the product is relatively stable after changing to JDK 5.0 then go 
ahead and mark it for a 2.0 and do a release candidate or two just to be 
sure.  Again there are no feature additions between release candidates. 
But if you're confident the release candidates may not even be necessary 
then just do a release without candidates.  You could have also jumped 
from 1.0 to 1.4 (or 1.6 or 1.8 etc) to convey the same meaning but a 1.0 
-> 2.0 jump might be louder and in line with a move to discontinue 
support for JDK 1.4.

Now if you want to jump to JDK 5 and continue adding features in a 
feature branch then make a jump from 1.0 -> 1.5 or from 1.0 -> 2.1. 
Again no matter what you do with the major number, make sure you jump 
more than 1 hop on the minor number and land on an odd minor number: 
1.3, 1.5, 1.7, 1.9 ... 1.23 or 2.1, 2.3 ... etc.

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

Ok then just jump to a 1.5 or to a 2.1 instead of an even release.  No 
one says you have to release a 2.0 and cannot skip it ;).

>     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.2 and 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.

Notes about stable minor number jumps:

Really nothing says you have to maintain the API across them.  It's nice 
to be able to sure! But this happens with really mature API's.  And 
certainly using the deprecation facilities is a polite thing to do.

An evolving API however will need to change rapidly.  However if a 
release early release often strategy is used there is a good chance to 
be able to use deprecations properly.

Again though minor number jumps do not mean you're guaranteed to have 
the same API.  Designers should try to use deprecations to protect 
against yanking APIs but can add new methods and classes as they please. 
  The occasional impolite surprise where you just lost that method or 
that interface might occur and is allowed as long as it's not going to 
force you to totally rewrite dependent software.


View raw message