Module ABI versioning

Fri Sep 18 19:56:47 UTC 2015

I'd like to appeal for a reconsideration on the stance on module
versioning, specifically, I'd like to ask for the simplest/most basic
possible versioning scheme (a single number) to be included in module
metadata.
My use case is a library like Guava. It hits the sweet/sour spot for jar
hell:
   1. Very widely used by both apps and libraries
   2. Iterates rapidly
   3. Releases are not backwards compatible
This can result in dependency deadlocks where upgrading one library is
impossible because it depends on Guava N, yet you're also using another
library that uses Guava M, and the two versions are not compatible. Modules
would fix this, except for the inability to distinguish the N and M modules.
One can argue, perhaps reasonably, that if two versions of a module export
classes with the same names but which aren't compatible then the modules
should have different names instead, i.e. an ABI version should be included
in the module name. Whilst this would work, it seems somehow ad hoc.
In the native code world this problem is solved for a long time already.
UNIX libraries do indeed include their ABI version in their "soname", but
it's done in a standardised way and every DSO built with the normal tools
includes an ABI version (libfoo.so.0).