Jan Schulz wrote:
IMO, they should go with the same strategy as the normal libaries: Changing names only when a API changed. So if 1.5 is API compatible to 1.4, the the jar should still be name-1.4.jar (or at least a symlink :) But if 1.5.3 breaks something, it should get name-1.5.3.jar. This is alos part of teh proposed debian policy. Debian will rename the jars in this manner, if that is accepted.
But libraries have the concept of software version, and then totally apart from this is the library version used by, for example, libtool, and meant to distinguish API incompatiblities.
I am not sure I'd want to mix the two. So in Java 1.5.3 is going to refer to the software version and not the API compatibility level, so I still think the jar should always be named with the full version. You're not going to get any libtool type versioning going with such a simple structure. You could attempt to make symlinks to every comptable version from 1.5.0 up to 1.5.3, but that just gets really messy.
I understand from a Debian perspective, you want to name your package libfoo1.5-1.5.3 and be done with it, but we have no guarantee of the API compatibility level. In Java, it *always* seems to be the case that it changes, even in *micro* releases, which is to say, that only libfoo1.5.3-1.5.3 may be sufficient for some software.
signed! Somehow I just relize, that we are putting up a list with points, but just rewriting rules, which are in use in c or any other language releases since ages :). I wonder if they had once the same problems :)
This might be true, but necessary. Anyway, these only exist in the free software world, which, until Java, existed mostly on non-Windows platforms. For the most part, every one in that world knows the rules and plays by them (not always, but they are the minority). With Java, we still don't know if it's simply the case that these are Windows developers who just don't know about the rules, or whether they just don't care to follow them. Clearly, in Java, these people are the majority, not the minority.
In short, just because you are I might be used to all of these things being second nature, they obviously aren't in the Java world, or we would even be here having this discussion, would we? :)
-- Sincerely, David Walluck <david@anti-microsoft.org>
Attachment:
signature.asc
Description: OpenPGP digital signature