Dependency Management: Phrases for Library Upgrades & Breaking Changes
5 exercises on dependency management vocabulary. Choose the most natural and professional option.
0 / 5 completed
1 / 5
You've discovered that a core library your team uses is no longer receiving security patches. How do you raise this?
"This library has reached end-of-life" is the precise technical and vendor-standard phrasing for software that no longer receives updates or security patches. "Before the next security advisory hits us" gives urgency without alarmism. Real examples: "Node 16 has reached end-of-life — we need to migrate to 20 LTS this quarter"; "OpenSSL 1.1 is EOL — any dependency on it is now a security liability." Options B-D describe the problem informally without using the accepted term, which weakens the case for prioritisation.
2 / 5
Your team wants to lock the dependency to prevent unexpected breaking upgrades from Dependabot. What do you recommend?
"We should pin the version to X.Y.Z" is the correct dependency management phrasing. Pinning to an exact version (not a range) prevents automatic upgrades. The "until we've validated the upgrade path" clause shows this is a temporary, deliberate choice — not negligence. Real examples: "Pin lodash to 4.17.21 — the 5.x upgrade has breaking changes we haven't assessed"; "We're pinning the ORM to 3.x until the migration guide for v4 is published." Options A/B/D avoid the technical term "pin" and are less precise.
3 / 5
You need to explain how your team will migrate from an old library version to a new one. What do you say?
"The upgrade path is: step 1, step 2, step 3" is the expected format for communicating a library migration plan. It shows you've thought through sequencing, risk mitigation (parallel run), and cleanup. Real examples: "Upgrade path: shim the old API for 2 weeks, migrate call sites, remove shim"; "Upgrade path is documented in the wiki — we'll use a compatibility layer through Q3." Options A-C are vague about the actual plan and don't name the mechanism.
4 / 5
A new major version of a key library introduces incompatibilities with your current code. How do you inform the team?
"There's a breaking change in v3 — X changed. Migration guide is at Y" is the complete breaking-change communication: it names the version, the specific change, and where to find help. Real examples: "Breaking change in v2: all async handlers now return Promises — check the upgrade guide"; "Breaking change in Axios 1.0: the error structure changed — migration steps in the release notes." Options A/C/D don't name the specific breaking change or point to a migration resource.
5 / 5
Before agreeing to add a new library to the project, what do you propose checking first?
"I'd audit the transitive dependencies first" is the expert's framing — it goes beyond the library itself to the full dependency tree. Mentioning licensing and security risks shows security-aware thinking. Real examples: "Audit the transitive deps before adding — that 'tiny' library pulled in 50 packages last time"; "Transitive dependency audit: this SDK brings in aws-sdk v2, which we're trying to eliminate." Options B-D are valid concerns but too surface-level; none address the hidden risk of transitive dependencies specifically.