Treat the objection as a request for an exception, not a veto. Let product teams file a short, time-boxed exception with evidence, let the platform team approve or decline within a set window, and make the pipeline enforce whatever is decided so the rule is the same for everyone.
Why a central pin causes friction
Central version control exists for good reasons. Maven lets a parent project manage versions in dependencyManagement. Gradle lets you add constraints that apply to transitive dependencies. pip supports a constraints file that, in the pip documentation's words, controls which version of a requirement is installed but not whether it is installed, and it suggests writing a single constraints file for an organization and using it everywhere.
The friction shows up when the pinned version breaks a product team's feature, or when a product team needs a version the platform has not blessed yet. Both sides are right about something.
Separate the pin from the policy
The platform team owns the pin. The product team owns its service. Disputes shrink when you write down what each side may do:
| Question | Platform team | Product team |
|---|---|---|
| Who sets the default version? | Yes | No |
| Who may request an exception? | Reviews it | Files it |
| Who owns breakage from the pin? | Shares it, helps fix | Reports it with a repro |
| Who owns risk from an exception? | Records it | Carries it, with an expiry |
An exception process that is fair
- The product team files a note with the package, the version they need, and the reason.
- They attach evidence: failing test output for the pinned version, or compatibility notes.
- The platform team answers within a fixed window, for example three business days.
- An approved exception has an owner, a scope (which service, which package), and an end date.
- The pipeline reads the exception, so the same check that blocks others lets this service through until the date.
A policy gate on pull requests is the natural place to enforce this. The gate stays strict by default, and exceptions are explicit entries rather than someone clicking past a failed check.
What the platform team owes in return
- A published schedule for moving the pin forward, so teams can plan.
- A staging path: a branch or pre-release channel where the next pin can be tested.
- Fast answers. A pin without a quick exception route breeds workarounds, such as local overrides that nobody tracks.
Local workarounds deserve special attention. Tools often allow a product team to override at its own root. That is allowed, but it should be visible. Scan for it, and ask for a record when you find one.
When the platform team should give way
If the pinned version carries a reachable, known vulnerability and the requested one fixes it, the pin should move. If the requested version is a major jump with unproven tests, the pin should hold and the exception should carry the risk. When it is unclear, take the question to the escalation path rather than arguing in the channel.
Quick check
Can a product team just override the pin locally?
Technically often yes, because root level overrides are supported. Organizationally, it should be a recorded exception with an owner and an end date, otherwise the central pin stops meaning anything.
How fast should the platform team respond?
Choose a window you can actually meet, commonly two to three business days, and publish it. Silence is the main cause of unofficial overrides.
Sources
Last reviewed: 19 October 2026.
