Repository navigation
docs(deps): DEPENDENCY_BUMP_AUDIT.md still says protobuf is capped below 7.0 and must not be raised — the tree ships >=7.36.0 #15622
Description
Problem
docs/developer/DEPENDENCY_BUMP_AUDIT.md still records protobuf as blocked
below a cap the tree raised months ago:
| **protobuf** | `>=5.29.6,<7.0.0` | `7.35.1` | **High** | ... **Do not raise
the cap until grpcio/opentelemetry support protobuf 7.** |
and its "Recommended upgrade order" repeats it: "protobuf — blocked until
grpcio + opentelemetry-* drop their <7 pins".
The tree does not agree. requirements.txt, autobot-backend/requirements.txt
and autobot-infrastructure/shared/docker/ai-stack/requirements-ai.txt all
declare protobuf>=7.36.0,<8.0.0, and requirements.txt carries the re-derived
rationale (#15070, #10678) explaining that opentelemetry-proto and
googleapis-common-protos now declare protobuf<8.0.
Why it matters
The doc is a dated snapshot (2026-06-21), but it does not read as history — it
reads as a standing instruction, and the instruction is to not do something
that has already been done. The next person auditing a protobuf dependabot PR
against this file would conclude the tree is in violation of its own policy.
Found while fixing #15597 (raising the ansible python_security_updates
protobuf floor from >=5.29.6 to the shipped >=7.36.0,<8.0.0) — the doc was
the only remaining place still asserting the old cap.
Acceptance criteria
- The protobuf row and the upgrade-order entry state the current pin and
what actually unblocked it (tech-debt(deps): the protobuf constraint and its inline rationale contradict each other in both requirements files #15070 / chore(deps): bump the all-dependencies group with 39 updates #10678), or the whole file is
re-dated and marked as a superseded snapshot - The other two deferred rows (
reportlab,structlog) are checked the
same way against the tree, so the file is not half-stale
Activity
docs(deps): correct the stale protobuf instruction and drop the orpha…
mrveiss commentedon Sep 4, 2026
Closed on code evidence, verified against merged
Dev_new_gui(PR #15647,21b27bf4). The "do not raise above 7.0" instruction is gone, and the file is retitled DISCHARGED.The doc was wrong in a second way nobody had asked about
The issue reported a stale number. Checking whether the reasoning still held at the new cap found the instruction had never been right:
grpciowas never a constraint. Both deployed grpcio versions (1.83.0, 1.82.1) declare zeroRequires-Dist: protobuflines — onlytyping-extensionsand agrpcio-toolsentry behind an unselected extra. The doc told readers to wait on a package that was not gating anything.The cap is a mirror, not a judgement.
opentelemetry-protodeclaresprotobuf<8.0,>=5.0andgoogleapis-common-protosdeclaresprotobuf<8.0.0. The ceiling read<7.0.0because they said<7; it reads<8.0.0because they now say<8. Both quoted verbatim and confirmed against deployed metadata in review.So the doc now records the mechanism — the ceiling copies the lowest upper bound protobuf's consumers declare, raised only when they publish a higher one — and tells readers to check that metadata rather than trust the sentence. Bumping the digit would have left a doc that says the right number for the wrong reason, and it would go stale again at the next bump for exactly the same cause.
Discharged, and the scope of that word is honest
All three deferred rows had landed:
protobuf>=7.36.0,<8.0.0,reportlab>=5.0.1,structlog>=26.1.0— each verified at every file the table names. The "Recommended upgrade order" listing protobuf as blocked is gone.Two stale records were deliberately excluded rather than folded in, and both are filed:
structlogfloors in the Windows NPU worker (>=23.2.0) and the local-setup guide sit 2-3 majors below the tree. Raising a floor in a separate deployable is an install-behaviour change, not a docs fix.DOCKER_MIGRATION_NOTES.mdis a dated snapshot whose pins are uniformly stale, includingprotobuf==5.29.5with a rationalerequirements.txtalready records as debunked. Correcting one pin among a dozen equally stale ones is worse than leaving the file uniformly dated..github/dependabot.ymlhad self-corrected but asserted the floor as>=7.35.1in the present tense when it is>=7.36.0— fixed, comments only, withversions: [">=8.0.0"]untouched. No other doc carried the cap as a standing instruction.