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

On Mon, Feb 23, 2026 at 6:40=E2=80=AFAM Sune Vuorela <[email protected]> wr=
ote:
>
> On 2026-02-23, Neal Gompa <[email protected]> wrote:
> > 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.
>
> I do think we could have much gain of having abi testing in our
> pipelines. I don't currently have time&energy to do it, but I've been
> reviewing tools and data for these for more than a decade, so I'll
> gladly look over one more.
>
> > 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.
>
> But this is not the expected way.
>

Actually, it's fairly rare that soversions match software versions in
Unix. To give you a deeply Unixy example: rpm itself doesn't link the
version to soversion[0] and uses soversion 10 for rpm 6.0. Libraries
like libtukit, libjpeg, libusb, libudev, libc (glibc), libbtrfsutil,
and libvirt are other examples where these don't match.

The historical convention is that there is zero relationship between
the software version and the ABI version, and libtool (which is the
progenitor of the ABI versioning convention everyone follows) has some
rules about this[1].

Plasma *mostly* follows these rules for its libraries.

[0]: https://github.com/rpm-software-management/rpm/blob/rpm-6.0.1-release/=
CMakeLists.txt#L47-L54
[1]: https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioni=
ng.html

> > If it bothers you that much.
>
> It does bother me.
>
>
> reviewing a change where things go from
>
> libfoo.so.6 =3D> libfoo.so.1.y.z
>
> libfoo.so.7 =3D> libfoo.so.1.y.w should also make reviewers do a double
> check because it is unexpected.
>
>
> Reviewer time is one of our most scarce resources. We should not do
> steps that takes up reviewer time if not needed. This is one of those
> steps.
>

To be honest, I don't think the number matters. Giving a signal that
something broke so the number needs to be bumped is considerably more
important.



--
=E7=9C=9F=E5=AE=9F=E3=81=AF=E3=81=84=E3=81=A4=E3=82=82=E4=B8=80=E3=81=A4=EF=
=BC=81/ Always, there's only one truth!