The grpc C++ libraries have CMake SOVERSION e.g. “1.48” for the 1.48.x minor release. There is no attempt at ABI compatibility across minor releases, and the entire string “1.48” is effectively a major version for ABI purposes. The “patch” relases of grpc only change internal implementation details. This approach is fairly common in C++ projects.
The grpc C libraries use a single integer that is bumped on some but not all minor releases. The CMake-based build system does not implement the libtool-style “age” semantics. The gtest library uses the entire project version number for the CMake SOVERSION, so the library for gtest/gmock 1.13.0 is “1.13.0”; this entire string is effectively a major version for the ABI. This is appropriate because upstream does not concern itself with ABI stability at all, so even patch updates must be considered to break the ABI. This is an even more common approach in C++-land. See flatbuffers for another example of this. On Mon, Feb 20, 2023, at 1:44 PM, Gordon Messmer wrote: > On 2023-02-20 02:16, Daniel P. Berrangé wrote: >> You mention 'libtool' multiple times through this thread. libtool >> defines specific semantics for 3 digits in the version number. >> Not all shared libraries are built with libtool, and even those >> which did use libtool didn't neccesarily apply libtool's semantics. >> >> Possibly this proposal works fine regardless ? In fact, presumably it >> must, otherwise its going to break stuff. >> >> If so, then I'd suggest removing references to libtool and describing >> directly what kind of versions it looks for and what it does with them. > > > Yes, the naming of things is a question I raised in the PR. I'm open to > suggestions. :) > > I'm also interested in looking at examples of non-libtool behavior, > since I'm proposing that we enforce versioning semantics where they have > not been enforced in the past. Can we find libraries that provide only > two dot-separated numbers? What about more than three? Can we treat > the first two as major.minor, or do we have examples where "minor" is > evidently a later number in the set? > > The currently open PR will only generate a versioned dependency if the > library's real name ends in ".so." followed by numbers and dots. If > there's a letter (e.g. libssl.so.1.1.1q), it doesn't get a version. > Mostly because: > > $ rpmdev-vercmp 1.2.3git 1.2.3 > 1.2.3git > 1.2.3 > > Is 1.2.3git a release from git leading up to 1.2.3, or is it a release > after 1.2.3 with fixes from git? > > How should maintainers handle packages where libraries have versions > that don't conform to the semantics we want? > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
