Trustin Lee wrote:
On 10/28/06, *Emmanuel Lecharny* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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.
HTH,
Alex
