Module ABI versioning

[Paul Benedict]

Mike, doesn't the semantic versioning scheme support this? There is no ABI
compatibility among major version changes. There might be ABI compatiblity
changes on minor versions (but I wouldn't rely on that). And patch versions
must have ABI compatibility.

Guava is using 19 for it's major version. So they had at least 19 ABI
incompatible changes. Though anything in the 19.0.X series would be fine to
swap, same with 18.0.X, etc.


Cheers,
Paul

On Fri, Sep 18, 2015 at 2:56 PM, Mike Hearn <hearn at vinumeris.com> wrote:

> 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).
>