Complicated versioning schema between various languages

[georgthegreat]

As I see, at the time the following rules apply:

• C++ protobuf releases version numbered {major}.{minor}
• Python protobuf adds 4. prefix to the versions (so git tag v21.12 becomes 4.21.12 on pypi).
• Java add 3. prefix to the versions (hence git tag v21.12 becomes 3.21.12.

In order to correspond to various versioning schemas, git tags also get multiplied, i. e. v22.0, v3.22.0 and v4.22.0 do actually point to the same commit a847a8d.

Is there any rationale behind this schema?
Do you have plans to unify the versioning?

[fowles]

This was a deliberate shift to allow language bindings to evolve independently. This was announced at https://protobuf.dev/news/2022-05-06/#versioning

The alternatives were

• bump major versions when any language needed a breaking change
• not bump major versions when some language did have a breaking change.
• never making breaking changes

All of these were unacceptable for various reasons, so here we are.

We should give this a dedicated space in our docs (not just the announcement section), so I will leave this bug open to track that.

[georgthegreat]

The problem is that making per-language versioning independent actually did not achieved this.

Code generation is still being done by C++ version of protoc which get released according to C++ versioning schema (i. e. every release is a breaking change).

Python bindings for protobuf still depend on a pyext (and have harsh performance if build without one).
As I am maintaining protobuf updates in our monorepo, I will indeed appreciate a doc section on this .

[Logofile]

https://protobuf.dev/support/version-support/ covers our versioning schema. If this doesn't fully address the things raised in this issue, please reopen this and provide a delta so that I know what you'd like to see added/changed. Thanks.

[acecilia]

Doing the following in a M1 mac:

curl -LO https://github.com/protocolbuffers/protobuf/releases/download/v23.3/protoc-23.3-osx-universal_binary.zip
unzip protoc-23.3-osx-universal_binary.zip -d protobuf
./protobuf/bin/protoc --version

Results in:

libprotoc 23.3

@Logofile is this expected?

[Logofile]

That output seems correct, yes. Were you expecting something different? If so, what and why?

[georgthegreat]

@Logofile, it is out internal problem, everything is correct with the protobuf.
However it would be more convenient for us, if protoc binary was produced by the linker, and protoc-${version} would be symlinked to it.