Dependency pinning
Dependency pinning fixes the exact version of every dependency (and transitively, every transitive dependency) so the same source produces the same build artefact regardless of when or where it's built. Without pinning, a 'patch upgrade' in a transitive dependency can change behaviour between builds run hours apart.
Pinning has two levels: declared dependencies (your package.json or requirements.txt) and transitive dependencies (everything declared dependencies depend on). Declared-only pinning is partial — a transitive can still float to a new patch version. Full pinning requires a lockfile (package-lock.json, yarn.lock, poetry.lock, Gemfile.lock) that records the exact tree. The tradeoffs: pinning produces reproducibility at the cost of explicit upgrade work; automated tools (Dependabot, Renovate) reopen the upgrade flow on a controlled cadence. The combination — full pinning plus automated upgrade PRs — is the practical reproducibility/maintenance compromise most modern teams adopt.
Related terms
- Lockfile
A lockfile records the exact resolved version of every package in a dependency tree — direct and transitive — so any subsequent install reproduces the same versions.
- Software bill of materials (SBOM)
A Software Bill of Materials is a machine-readable inventory of every component, library, and dependency in a software artefact — typically in SPDX or CycloneDX format.
- Semantic versioning (semver)
Semantic versioning is the package-versioning convention MAJOR.