A single org-wide version suits shared libraries and security sensitive packages, because one fix lands everywhere. Per-team versions suit loosely coupled services with different release speeds. Many orgs use a hybrid: one managed version for a small core list, team choice for the rest, and a clear owner for each.
Two approaches, defined
One version policy. A central list sets the version of a package for every build. Maven calls this dependency management, and a parent project can control which version is used when a package is referenced. A pip constraints file is a similar tool for Python.
Per-team versions. Each team picks versions in its own manifest and lockfile. Nothing is shared, so nothing blocks anyone, but nothing is consistent either.
Comparison
| Factor | One version | Per-team |
|---|---|---|
| Time to ship a security fix | One change, one rollout | One change per team |
| Risk of a surprise break | Higher, many services at once | Lower, blast radius is one team |
| Coordination cost | High, needs an owner | Low day to day |
| Inventory clarity | Simple: one version to track | Many versions to track |
| Autonomy | Lower | Higher |
| Drift over time | Low | High, unless audited |
Neither column wins everywhere. The honest answer depends on how tightly your services share code.
Where one version pays off
- Libraries compiled into many services, such as logging, serialization or HTTP clients, where mismatched versions can cause runtime errors.
- Packages with frequent advisories, because a single place to fix is faster than chasing many.
- Regulated or customer facing builds where you must answer "which version do you run?" with one line.
Maven's rule shows why consistency needs a decision. When two versions of an artifact appear in the tree, Maven picks the nearest definition to your project, and you can always guarantee a version by declaring it explicitly. That guarantee is useful only if somebody owns the declaration.
Where per-team versions are fine
- Developer tooling, test frameworks and build plugins, where a mismatch rarely reaches production.
- Services that talk only through versioned APIs and share no code.
- Teams moving at different speeds that would otherwise be held back by the slowest member.
Even here, set a floor. A rule such as "no version with a known fixed advisory older than 30 days" lets teams choose freely above a safe line.
The hybrid most orgs settle on
- Name a small core list, perhaps 20 to 50 packages, that the platform team manages centrally.
- Everything else is team choice, subject to a policy gate that checks advisories.
- Each core package has an owner and a review date.
- Exceptions are recorded with an end date.
- Revisit the core list twice a year. Add packages that caused disputes, remove ones that did not.
Start from data. An inventory of versions across repositories shows which packages already drift and which ones cause trouble, so the core list is built from evidence, not opinion.
Quick check
Does a central version list remove the need for lockfiles?
No. The central list says which versions are allowed or preferred, and lockfiles record what each build actually resolved. You need both.
How big should the central list be?
Small enough that the platform team can actually review it. Start with packages that have had disputes or advisories and grow only when there is a reason.
Sources
Last reviewed: 19 October 2026.
