search

Ultimaker / libArcus

Communication library between internal components for Ultimaker software
GNU Lesser General Public License v3.0
76 stars 81 forks source link

SOVERSION / VERSION / Cura version mismatch #52

Open onitake opened 7 years ago

onitake commented 7 years ago

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.

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 commented 7 years ago

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 commented 7 years ago

Ok, that's good to hear.

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

Would this break compatibility with older library versions?

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

awhiemstra commented 7 years ago

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 commented 7 years ago

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