Trustin Lee a écrit :
On 10/28/06, Emmanuel Lecharny <[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?
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
Emmanuel.
