search

mypaint / libmypaint

libmypaint, a.k.a. "brushlib", is a library for making brushstrokes which is used by MyPaint and other projects.
http://mypaint.org
Other
310 stars 86 forks source link

libmypaint has version string in lib name #174

Closed hosiet closed 4 years ago

hosiet commented 4 years ago

I noticed that libmypaint is building shared libraries that has version string stored in library name. For example, Current libmypaint v1.6 provides libmypaint-1.6.so.1.1.2.

Changing library name with each release would break binary compatibility. For example, if some older executables are linked with libmypaint 1.5, it will be looking for libmypaint-1.5.so.1, which does not exist after upgrade of libmypaint. Generally binary compatibility should be kept unless the library inevitably introduces ABI breaks, in which case the library should be bumping SONAME.

As far as I can tell libmypaint 1.5 and 1.6 does not have any ABI incompatibility (other than the newly-introduced function in 1.6). Is there any reason of bumping version string in library name in each release instead of bumping SONAME? Ideally there should be libmypaint.so.1.5.x for libmypaint 1.5 and libmypaint.so.1.6.x for libmypaint 1.6. The SONAME is kept to be 1 here since they are ABI backward-compatible. (Of course SONAME should be bumped when needed and is not necessarily bounded with $version_major.)

I'm writing this because I noticed such breakage when trying to upgrade libmypaint in Debian. Such change in library name will require another round of rebuild for all reverse-dependencies of libmypaint, including important software like GIMP.

jplloyd commented 4 years ago

As far as I know, there is no good reason for it. It was set up in that way (e56d62694df335a67b8ca5fc8e3c6d2f2c4a19a9) from before the first release, perhaps without full knowledge of the consequences.

I should have removed the -release flag for 1.5, so that the abi version fields would be meaningful for future releases (including 1.6), though one could argue that doing so would have been confusing as well.

The -release flag is no longer used in master (though the setup there is currently even worse, for other reasons, and needs to be fixed as well).

What do you suggest for the 1.x branch? A re-release of 1.6 that changes the library name to match 1.5, or that just drops the -release flag and resets the abi fields? The latter option doesn't solve the issue for this release, of course, but would make any future 1.x releases more sane, in terms of version info.

hosiet commented 4 years ago

I'd suggest the latter one (dropping manual -release flag) to make future 1.x releases sane, which has long-term benefits. We downstream distributions can always apply a patch as an interim solution. Thanks!

jplloyd commented 4 years ago

Alright, so just to be clear, the thing to do here would be to:

hosiet commented 4 years ago

Sure; that would be a clean restart. I guess some testing would be needed before actually tagging 1.6.1 though.

jplloyd commented 4 years ago

Ok, thanks. There have been literally 0 commits to the v1 branch since the 1.6.0 release (because I forgot to increment the working version again), but I might as well double check the functionality. I'll probably do the release tomorrow.

jplloyd commented 4 years ago

Version string is now no longer part of the lib name.

https://github.com/mypaint/libmypaint/releases/tag/v1.6.1