Relax protobuf upper bound for protobuf 6/7 compatibility

[alario-tang]

Hi, thanks for maintaining aliyun-log-python-sdk.

The latest release 0.9.46 still declares this protobuf dependency range:

protobuf>=3.20.3,<6.0.0

This upper bound prevents projects that use newer protobuf-based libraries from resolving dependencies in the same Python environment. For example, applications that use ConnectRPC / generated protobuf clients may need to integrate with protobuf 6+ compatible packages, but aliyun-log-python-sdk forces the environment to stay on protobuf 5.x.

Would you consider testing aliyun-log-python-sdk with protobuf 6/7 and relaxing the upper bound if compatible? For example:

protobuf>=3.20.3,<8.0.0

or another validated compatible range.

Current workaround on our side is to keep runtime protobuf on 5.x, but this makes integration with newer protobuf ecosystem packages harder.

Environment observed:

• aliyun-log-python-sdk: 0.9.46
• Resolved protobuf due to this constraint: 5.29.6
• Python: 3.13 / 3.14

Related older protobuf compatibility issues exist, but they appear to target protobuf 4-era breakage rather than the current upper-bound constraint for protobuf 6/7 compatibility.

[alario-tang]

Additional context on why protobuf 7.34.x would be a good target to validate against directly:

• 7.34.x is the current active-support Python protobuf line, while older lines are either in maintenance or already out of support.
• It aligns with the current Protobuf 34.x / modern code-generation ecosystem, which is what newer Buf / ConnectRPC / generated-client workflows tend to track.
• It keeps older Python generated code migration smoother because Python 7.34.x does not emit the same poison-pill warning/error for stale generated files that some intermediate versions may surface.
• It tightens runtime behavior in useful ways, for example stricter bool/int/enum handling and clearer type errors for Timestamp / Duration conversion. This helps catch data-shape bugs earlier.
• It keeps downstream applications from being pinned to protobuf 5.x solely because of the SDK dependency range.

So from a downstream integrator perspective, the most useful outcome would be testing and supporting protobuf 7.34.x directly, rather than only relaxing the upper bound to protobuf 6.x.

A possible target range, if your compatibility tests pass, could be something like:

protobuf>=3.20.3,<8.0.0

or a narrower validated range that includes 7.34.x.