Trustin Lee wrote:
On 10/29/06, *Alex Karasulu* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
