This patch is for the release/11.x branch. We need to bump the SONAME, because
the ABI of the shared library is changing
commit a8b717fda42294d1c8e1f05d71280503e5839f14 Author: Sylvestre Ledru <email@example.com> Date: Thu Mar 29 10:05:46 2018 +0000 Rename clang link from clang-X.Y to clang-X Summary: As we are only doing X.0.Z releases (not using the minor version), there is no need to keep -X.Y in the version. So, instead, I propose the following: Instead of having clang-7.0 in bin/, we will have clang-7 Since also matches was gcc is doing. Reviewers: tstellar, dlj, dim, hans Reviewed By: dim, hans Subscribers: dim, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D41808 llvm-svn: 328769
But this seems to have been mainly about the clang executable that gets installed into $prefix/bin, i.e. clang-11 instead of clang-11.1.
I think this doesn't matter for the clang executable here, since nobody uses its ABI. But indeed for the shared library it looks like a good solution, if you would want to install both versions side-by-side.
Yeah, my question is more "is that enough for distro?"
I might be wrong but if 11.1 and 11.0 aren't compatible (not just adding a new function), I was wondering if if should not be 12 (I know it is terrible).
Maybe we can expect that packagers will know that 11.1 is like a 12 in term of soname
If the SONAME is different in any way, it is totally distinct to the dynamic linker. There's no semver parsing or anything like that. That's all we can do from a technical perspective, and the rest is just communication in the release.
I see those links, but also lib/libclang-cpp.so.11.1 -> libclang-cpp.so.11, with the latter being the real file. If I add VERSION explicitly, that goes away.