On Thu, Apr 20, 2006 at 02:07:31PM +0200, Peter Eisentraut wrote: > 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. [...] If you don't believe Java libraries have issues with not regularly supporting backward compatibility, then I would wonder how much enterprise development experience you have with Java libraries ;-). > > 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.
I think you make some excellent points here. In your initial message, I thought you were advocating the dropping of version numbers and not trying to do anything else, which I would consider reckless and unwise. Adopting a solution for languages that have a longer history in Debian with some proven solutions seems like a wise approach to me. So, Debian Java Maintainers, let's hear from you on this! We have to work this topic out if we are going to get a decent Java policy ready at any point in the near future. Regards, -- Barry Hawkins All Things Computed site: www.alltc.com weblog: www.yepthatsme.com Registered Linux User #368650
signature.asc
Description: Digital signature
