Bug#363165: [PROPOSAL] drop version number from jar installations

[Peter Eisentraut <peter_e@gmx.net>]

Am Dienstag, 18. April 2006 22:23 schrieb Barry Hawkins:
>     I replied to that posting[0], and I don't think the discussion yielded
> a lack of support for using version numbers in .jar file names.

The points you listed are:

1.) Java(TM) libraries have a notorious tendency (not unlike other languages)
    to not preserve backward compatibility between significant revisions.
    [...]

This may be true (although I don't believe it) but the current system does 
nothing in the way of solving it.

2.) A given library may have multiple versions within the Debian repository at
    a given time.

That means that *if* a package has multiple versions in the archive, then a 
versioning mechanism has to be used.  But many packages don't need this.

> What is the significant gain you propose by not having version numbers?

Simplification.

> The version numbers are a lightweight (though imperfect) means of dealing
> with the inevitable situation of incompatibilities between versions of an
> API.

That's the point.  They don't actually deal with it.  At least not with a lot 
more infrastructure that I don't see defined anywhere.  For instance, if this 
is supposed to be supported, then all Jar references in other packages would 
really need to be versioned.  And there would need to be some way of having 
major/minor version numbers, so an upgrade from version 2 to 3 would create 
an incompatibility but an upgrade from 2.0.1 to 2.0.2 would perhaps not.  And 
the version is currently required to be the version number of the package, 
which says nothing about compatibility.  C library sonames are distinct from 
package versions.

If there is a feeling that managing C library-like soname upgrades is useful 
for Java libraries, then I would certainly support that.  But the current 
system is a solution in search of a problem.

> For example, when a maintainer is packaging a Java API that depends 
> on the Jakarta Commons HTTPClient version 3.0, they at least can see that
> the symlink commons-httpclient.jar points to commons-httpclient-2.0.2.jar
> and have some insight as to why their package isn't behaving properly.

That sort of argument would call for symlinking everything to versioned files 
(think /bin/sed-4.1.4).  This is not a Java-specific problem.  If you want to 
know the version of a file, use dpkg.