All,
the trials and tribulations associated with the release has made me
think about
version numbers a lot. I use Cocoon, and there's always a bit of
press-enter-
and-pray-to-god when trying out a new version of some dependent library.
The problem is that if you have libraries A and B, A is depndent on B
and both
are dependent on C, and they somehow end up being dependent on
*different*
versions of C, then it is not always possible to get things to run at
all.
Consider this:
A -dep on-> B, C-1.3
B -dep on-> C-1.4
The obvious solution for the case above would be to deploy C version
1.4.
However, this may not always solve the problem if C-1.4 isn't backwards
compatible with C-1.3.
There's little that can be done in such a case, so I was thinking about
ways to keep it from happening.
What one could do is to compare classes in the latest released jar,
and in the jar just built: If a class exists in old.jar but not in
new.jar, well, that's a major version number bump (not backward compat).
Comparing classes from both jars:
1. If two classes have the exact same public and protected methods,
they are both forward and backwards compatible. Increase patch
version
number.
2. If a method has been added to a class it is backwards compatible.
Increase minor version number.
3. If a method has been added to an interface:
a. If the interface isn't implemented by clients:
Increase minor version number.
b. If the interface is implemented by clients:
Increase major version number.
4. If a method has been removed from a class:
Increase major version number.
5. If a method has been removed from an interface:
a. If the interface isn't implemented by clients:
Increase major version number.
b. If the interface is implemented by clients:
Increase minor version number.
The above could be made into an Ant task.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
