You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently set a minimum version of the runtime `protobuf` package for
protocolbuffers/python based on the documented ["new gencode + old
runtime = never allowed"][1] rule that generally applies to the
protocolbuffers plugins - that the runtime versions are free to add
runtime APIs in any release and it's expected that the gencode must be
updated to run with the new runtime version.
However, [Python has a separate carve-out behavior for its gencode][2],
documented now as:
> Since the 3.20.0 release, the Protobuf Python generated code became a
> thin wrapper around an embedded FileDescriptorProto. Because these
> protos are supported on extremely long timeframes, our usual major
> version compatibility windows aren’t typically necessary.
> Python may break generated code compatibility in specific future major
> version releases, but it will be coupled with poison pill warnings and
> errors in advance. As of 6.32.0, all generated code since 3.20.0 will
be
> supported until at least 8.x.y.
This means that we don't need to pin the protocolbuffers/python version
to the matching runtime version; we can loosen the minimum to `3.20.0`
(and will need to reevaluate this in the future v8 major release).
This commit pins the latest minor release in each major version to a
minimum of 3.20.
An alternative is to _just_ specify `protobuf` without any version
specifiers, and allow consumers to pick the version of `protobuf` they
want to supply. But since the minimum is pretty clearly documented, I
think supplying it is reasonable.
[1]:
https://protobuf.dev/support/cross-version-runtime-guarantee/#backwards
[2]:
https://protobuf.dev/support/cross-version-runtime-guarantee/#python
---
* The [first
commit](8e4141a)
applies the above on the latest minor release of each major version of
protocolbuffers/python (and protocolbuffers/pyi, which
protocolbuffers/python depends on).
* The [second
commit](289a3e8)
does the rest of the versions. We can revert this commit if we'd like,
but I think it would be better to update all of these in one shot to
avoid confusion.
* The [third
commit](72a8bc5)
is optional, but in the same vein: we currently set a fairly strict
lower bound on the `types-protobuf` dependency of protocolbuffers/pyi,
but we don't have any real guarantees about how those versions map to
the runtime version. I think we ought to loosen them to just allow the
user to figure out the version they want. Again, we can revert this, but
I figure we ought to do this update in one-shot.
0 commit comments