SemVers broken on protobuf-config.cmake

[Finkman]

What version of protobuf and what language are you using? Version: 23.3 Language: C++

What operating system (Linux, Windows, ...) and version? Ubuntu 22.04

What runtime / compiler are you using (e.g., python version or gcc version) Shipped gcc-11

This Article tells, that protobuf is using SemVer. This versioning defines which kind of changes are reflected to the version. An breaking API change will always bump major version.

As far as I understood is the major version coupled with the language, which allows API changes in that language to take place without impact to other languages. In case of protobuf-config.cmake - which ships with the cmake-install - this major version is not visible. Moreover, the minor-version became the major and the patch became the minor. The original major is missing at all.

Consequences:

• Every call like find_package(protobuf 4.99.2) will succeed. Since the protobuf-config.cmake reports 23.3.0.
• If I tied find_package to search for all within 3.21.0...3.99.3 cmake complains that 23.3.0 is not within range.

find_package(protobuf 3.21.0...3.99.3 REQUIRED CONFIG)

[cmake]   Could not find a configuration file for package "protobuf" that is
[cmake]   compatible with requested version range "3.21.0...3.99.3".
[cmake] 
[cmake]   The following configuration files were considered but not accepted:
[cmake] 
[cmake]     /usr/local/lib/cmake/protobuf/protobuf-config.cmake, version: 23.3.0

Since protobuf > 3.21. brings some changes in cmake scripts it is mandatory to check for an installation with at least that version or higher which is not possible so far.

Expectation:

If protobuf 3.23.3 is installed, I expect protobuf-config.cmake to report version 3.23.3, not 23.3.0

[mkruskal-google]

There's a bit of an ambiguity here because our cmake configs are for both protoc and the C++ runtime. Right now we're setup to use the protoc versioning scheme, in which every release is a potentially breaking change (you should always regenerate your proto files for the runtime version you're on). If we switched to the C++ runtime version numbers, it would then imply that protoc version bumps are safe even when they're not (notably if you're using protoc to generate code for a non-C++ language that had a major version bump).

We could potentially ship two cmake packages with different versioning semantics, but that's a major breaking change to all our users. Could you just check for >= 21.0? We do guarantee that our minor version numbers are strictly increasing (to match the fact that they're protoc major version numbers)

[Finkman]

I understand your point regarding protoc. But as an library user, protoc is shipped with the library, so it is tight coupled. The issue an library user faces is not protoc to lib. It is user code to lib. My code must be api compatible with the protobuf lib. For this protobuf claims to use SemVers. And as I wrote before: The issue is, that you report the minor version as a major version doing this violates SemVers and lead CMake to reject V22.x if >V21.x is requested. this has nothing to do with your internal tooling. By the way, the config script is complaining about miss match in the versioning to protoc (regarding same versioning transformation) but this will be another issue,

[mkruskal-google]

I'm not talking about anything internal here. If someone uses cmake to generate code for non-C++ languages via protoc, the version of the C++ runtime would be completely incorrect. I think the root problem is that:

1. we ship both protoc and the C++ runtime under the same cmake package
2. protoc and the C++ runtime have different version schemes
3. there is an additional constraint on any project using runtime version x.y.z that they also be using generating code with protoc version y.*

I think the proper solution here is to ship multiple cmake packages, one for protoc and one for each runtime. We could then declare 3) as a find_package constraint. But like I said, this seems like it would be a major breaking change for all cmake users. We might want to consider bundling this in with our upcoming cmake cleanup though (@coryan FYI)

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

[Finkman]

I guess, it should still be on focus since it is still breaking SemVers.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

[Finkman]

@mkruskal-google or @coryan, is there any (planned) activity to fix this issue?

[coryan]

I no longer have time to work on this, sorry.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please reopen it.

This issue was closed and archived because there has been no new activity in the 14 days since the inactive label was added.