Let's do SOVERSION according to traditions and documentation

[Neal Gompa]

On Mon, Feb 23, 2026 at 6:04 AM Sune Vuorela <nospam at vuorela.dk> wrote:
>
> Hi people
>
> Historically and conventionally, abi versioning of libraries on
> especially unix-like systems, have resulted in
>
> libfoo.so.6 => libfoo.so.6.2.3 for e.g. SONAME libfoo.so.y.
>
> In CMake, you would express this with
> set_target_properties(mylib PROPERTIES VERSION 1.2.3 SOVERSION 1)
>
> where the first point of VERSION x.y.z matches what you pass to
> SOVERSION.
> There is nothing in the machinery than hard enforces this, although it
> is documented in the CMake documentation as 'common convention':
>
> With older tooling like libtool, it is not possible to make these
> different.
> Meson allows making it different, but the the documentation tries hard
> to direct the user to not do that.
>
>
> In https://invent.kde.org/plasma/libplasma/-/merge_requests/1439 Harald
> suggests to divert from the long established norm so that we have
>
> libplasma.so.7 => libplasma.so.6.6.1 confusing both humans and scripts,
> and wants a discussion on k-c-d wether or not we should follow
> historical norms or not.
>
>
> It is also surprising because one might have libfoo.so.6 =>
> libfoo.so.6.6.0 nad libfoo.so.7 => libfoo.so.6.6.0 symlinks in the same
> hand compiled sessions.
>
> So, Harald asked me to start a discussion here wether or not we should
> divert from expected.
>
> This (the ability to have SONAME and x in x.y.z VERSION diverge) is a
> footgun that we should not use.
>
> So, what should we do ?
>

I don't think this is a footgun. SOVERSION describes the ABI version,
while VERSION describes the software version. CMake correctly handles
this by making the actual ELF image use the SOVERSION. If there was
anything we *might* do, it's dropping the VERSION setting. But I don't
think it matters to drop it.

This hasn't been an issue for us as developers or distributors,
because it's an easy thing to handle. What we probably need to start
doing is integrating ABI testing into our pipelines so that when an
ABI break happens, the CI in a merge request fails and blocks the MR
from landing until the soversion bump occurs.

Distributions generally have good tools to handle ABI bumps when they
are done in expected ways and there's good signal. When that doesn't
exist, everything is a mess.

If it bothers you that much, we could change it to match the Plasma
feature version (so SOVERSION would be set to MAJOR.MINOR), but that
would still require us to have ABI testing (leveraging libabigail and
such) so that we can block accidental ABI breaks. And it would still
drift because libplasma's SOVERSION isn't supposed to get bumped every
cycle, so it won't match VERSION regardless.

>From my point of view, this discussion is a red herring and doesn't
actually solve the problems users, developers, or distributors have.



--
真実はいつも一つ！/ Always, there's only one truth!