SOVERSION / VERSION / Cura version mismatch

[onitake]

I ran into this problem while attempting to package Cura up for Debian:
There seems to be a general disagreement over which versioning scheme to use for libArcus.

• The "release" uses the same scheme as Cura (ex. 2.3.0)
• The library version is currently 1.1.0
• The SOVERSION (i.e. API level) is 3

While technically not an issue, it is highly confusing and causes lintian to throw a tantrum. Silencing it is an option, but I'd rather have an official opinion why Arcus doesn't use a more consistent versioning scheme.

Even better, it would be nice if the three versions would match up.
I understand that this will most likely introduce a discrepancy between Cura and libArcus, but I don't think it will be a major problem. One can always require a specific library version, if necessary.

[awhiemstra]

The versions are mismatched because I have not yet finished decoupling Arcus from Cura's release cycle. The correct version here is 1.1.0 (or maybe 1.1.1) to indicate it is a separate release. I just have not yet had the time to make it a proper separate release.

[onitake]

Ok, that's good to hear.

In this case, I would like to tag the Debian package as follows:

• Package: libarcus-1.1.0-1
• Library: libArcus.so.1.1.0
• SOVERSION: 1

Would this break compatibility with older library versions?

An alternative, taking API changes into account, could be:

• Package: libarcus3-1.1.0-1
• Library: libArcus.so.1.1.0
• SOVERSION: 3

[awhiemstra]

Hmm, why does the SOVERSION need to be 1? On the other hand, if it is a requirement for Debian packages I am fine with changing the soversion to 1.

[onitake]

Well, the SOVERSION is something like the API level of a shared library.
It is normally only incremented when breaking changes are introduced.
I don't know how stable the API of Arcus has been until now, so it's up to you to decide which version is correct.

Setting it to 1 would synchronize it with the library version, but having different versioning is perfectly ok too. The important thing here is consistency, so a package doesn't need changes every time a new upstream release is made.

The most well-known example for non-synchronised versioning is probably the GNU C library:
Its API level (and thus SOVERSION) is 6, the resulting SONAME is libc.so.6, but the actual version is something like 2.24. This results in the Debian package libc6, version 2.24-9 for example. Programs are linked against the SONAME:

$ ldd /bin/bash
...
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 ...
...