Re: Let's do SOVERSION according to traditions and documentation

Hello,

In plasma, we operate under different conditions. We can break ABI 
there. On the other hand, if you consider KF, you cannot break API or 
ABI compatibility, so you could lock the SOVERSION at the major version 
and have them both match.

In plasma, since we can break ABI (we even moved some projects to plasma 
in order to be able to make breaking changes), locking the SOVERSION 
like that is simply not applicable.

Regards,
Vlad

On 2/23/26 1:03 PM, Sune Vuorela 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 ?
>
> /Sune
>