On this page
Research context
This protocol asks how often a dependency upgrade changes the runtime or platform versions that a service supports. The unit is one dependency upgrade release, identified by the package, the old version, and the new version. The study measures whether the release notes declare a runtime change, whether the build and deployment configuration changed, and whether the change was verified in the target environment. It does not evaluate whether the upgrade was worth doing.
Set the scope to one service, one package manager, and one deployment platform. Record the runtime versions in the build image, the production image, and the developer documentation at the start. If the platform changes during the window, keep the earlier definition for the full sample or analyze the change as a separate period. A platform migration can look like dependency drift when it is only a separate change.
Define the population as every dependency upgrade that reached a release decision during the window, including upgrades that were postponed. The unit is the upgrade release, not the package version, because a release can include several packages. A security patch applied separately is a new unit. A rollback and re-release is a new unit with a link to the earlier release.
Record the package, the version change, the runtime, and the deployment platform. These strata matter because a patch upgrade and a major upgrade carry different compatibility risk. Include upgrades that were reverted, because the reversal is part of the process. Test the unit definition on two ordinary upgrades before collection begins.
Define a runtime change as a change to the minimum or maximum supported version of the language, framework, operating system, or database. Define a declared change as one stated in the release notes or migration guide. Define a verified change as one observed in the build, deployment, or target environment. Define silent drift as a runtime change that was neither declared nor verified.
Do not count a change to a development-only tool as a runtime change unless it affects the build output. Do not count a change that only updates a type definition without a runtime effect. A change that is declared but not verified is not silent, but it is still incomplete. Each definition should include one positive example and one boundary example.
For each upgrade, capture the package, the old and new versions, the release date, the runtime before and after, and the platform before and after. Add whether the release notes declared a runtime change and whether the build configuration changed. Record the verification environment and the observed result. Keep the packet with the release record.
Practical application
Also capture whether the development documentation was updated and whether the change affected a supported customer environment. These fields help explain a runtime change that was technically valid but unsupported for a customer. If the version was inferred from a lockfile, record the lockfile date. A second reviewer should be able to reconstruct the compatibility change from the record. Keep the packet with the release record.
Draw the sample from the dependency update system and the release log rather than from a list of incidents. Record the export date, the filters, the row count, and the selection rule. Include upgrades from every package group and every runtime so the result is not dominated by one ecosystem. If the population is ordered by release date, a fixed interval spreads the sample across the window.
Collect the lockfile and build configuration as they existed at the release, not as they look after later edits. If the runtime was changed after the upgrade, record the separate change and analyze it independently. Do not infer a runtime change from the absence of an error. Note the collection date separately from the release date.
A useful additional measure is the number of services that share the same runtime constraint. One upgrade can affect several services even when only one repository changes. Record the shared constraint, the services it covers, and the owner of the upgrade plan. That view helps the owner plan a coordinated upgrade instead of discovering the dependency during the next release window.
Report the number of upgrades, the share with a declared runtime change, the share with a verified runtime change, and the share with silent drift. Show the counts by package group and runtime. Present the share of upgrades that updated the documentation and the share that affected a supported customer environment. Use the same denominator for every rate.
Inspect the silent drift cases and describe the pattern without naming the engineer. A cluster in one package group may point to a missing release-note check, while a cluster in one runtime may point to a platform dependency. Compare the result with the upgrade type, because a major upgrade is more likely to change compatibility. Report the reverted upgrades separately.
A useful additional view is the time between the upgrade and the documentation update. A runtime change that is verified but undocumented can surprise the next engineer or a customer. Show the gap and describe the consequence. That view helps the owner decide whether the documentation step belongs in the release gate.
Operating controls
The review should also compare the declared support policy with the customer environments the service actually serves. A runtime version can be supported by the vendor but unsupported by a customer. Record the customer support matrix and the change. That comparison shows whether the upgrade needs a customer communication.
The record cannot show whether the runtime change actually broke a customer workflow. It can show only whether the change was declared, verified, and documented. A declared change is not proof of compatibility, and a silent change is not proof of breakage. The protocol also cannot capture a customer environment that the team does not control.
Release notes can be incomplete, and a package can change behavior without changing the declared runtime range. A lockfile update can resolve a different transitive version than the one reviewed. Record those cases and their treatment instead of dropping them silently. If the same person upgraded the package and verified the runtime, note the independence limitation.
A useful check is whether the build image and the production image use the same runtime. A build that passes on a newer runtime can still fail in production if the images differ. Record both versions and the verification environment. That gap is a deployment problem that a dependency review can catch early.
Give the result to the engineering lead and the platform owner and ask them to choose one observable change. The change might be a required runtime check, a documentation update in the release template, or a supported-version matrix review. Record the owner, the effective date, and the measure that will show whether the change worked. Avoid changing the template and the runtime policy at the same time.
Repeat the protocol with the same definitions after the change and compare the same fields. If declared changes improved but verification did not, the team may be reading notes without testing the target environment. If verification improved but documentation did not, the handoff may still be incomplete. Close the review when the owner accepts the finding and the next sample is scheduled.
The final view is the time between the dependency release and the team's adoption. A very old dependency may carry unpatched vulnerabilities, while a very new one may not have ecosystem support. Show the age and the support status beside the upgrade decision. That context helps the owner choose a sustainable cadence. Record the next review date with the sample.
Sources
Frequently asked questions
What should happen first?
Begin with a bounded ticket, approved access, explicit acceptance evidence, and a named reviewer.
Who approves production changes?
The client's technical owner keeps final merge and release authority.
Related research
How often do outsourced pull requests arrive without a reproducible test?
Where does review time accumulate in a distributed engineering team?