skip to content

How would you set an Angular upgrade policy across many apps and shared libraries so that none falls out of support?

level: principalimportance: should knowfreq 30%

answer

  1. a yearly major is a budget
  2. lockstep versus independent
  3. peer ranges on shared libraries
  4. never more than one major behind

basics

~20 s

Treat Angular's yearly major as a fixed annual upgrade budget, keep every app within one major of current so it stays supported, and choose between lockstep upgrades and per-app upgrades with shared libraries spanning two majors.

solid answer

~50 s

I would start from the policy: since v22 a major ships about every 12 months and is supported for 24, so **any app within one major of current is always supported**; that becomes the rule. Each team gets a **yearly upgrade window** after the new major's first patches, and deprecations are cleared continuously during the year. The big choice is **lockstep versus independent**: a monorepo upgraded in lockstep means one migration effort and one version, but the slowest app blocks everyone; independent upgrades give autonomy but force shared libraries to declare peer ranges spanning two majors and to test against both. I would also run a **canary build** against `-next`/`-rc` pre-releases, restrict developer preview and experimental APIs in shared libraries, and report every app's LTS end date on a dashboard so nobody discovers the deadline late.

go deeper

for a junior

Recall the facts the policy rests on: yearly majors, 24 months of support, one major at a time.

for a middle

Explain why keeping every app within one major of current keeps it supported, and what minors and patches cost to take.

for a senior

Show how you would run the yearly hop for several apps: canary builds on pre-releases, library readiness, and deprecations cleared ahead of time.

for a principal

Argue the lockstep versus independent tradeoff for your organisation, and define the deadline, dashboard and ownership that enforce it.

For one app, an upgrade is a task. For an organisation with dozens of Angular apps and a set of shared component and utility libraries, it is a **policy problem**: who upgrades when, what blocks whom, and how you prove nothing is running on an unsupported major. There is no single right answer; there are tradeoffs to choose deliberately. ## Start from the published constraints - A **major every 12 months** since v22, with 4-6 minors in between. - **24 months of support** per major: 12 active, then 12 LTS with only critical and security fixes. - Updates go **one major at a time**. - **Deprecated APIs survive at least one major**, and removals happen only in majors. - **Minors and patches are backward-compatible**, and peer dependency ranges only widen in minors. From these follows the one rule everything else serves: **an app that stays within one major of the current release is always inside a support window**. Two majors behind means sitting on an LTS release close to its end, with two sequential hops to do. ## Choice 1: lockstep or independent | | Lockstep (one Angular version for all) | Independent (each app on its own schedule) | | :-- | :-- | :-- | | **Upgrade effort** | One coordinated migration, often by a platform team | Each team pays its own upgrade cost | | **Shared libraries** | Target exactly one major | Must support a range, usually current and previous major | | **Blocking** | The slowest app or library blocks everyone | Laggards only block themselves | | **Risk of drift** | Low: one version to track | High without enforcement | | **Fits** | A monorepo, strong platform team | Many repos, autonomous teams | Many organisations end up with a hybrid: shared libraries and a core set of apps in lockstep, with a bounded grace period for the rest. ## Choice 2: when in the year to upgrade - **Early adopters** move in the first weeks after a major ships and catch problems while the major is fresh. - **Most teams** wait for the first patches and for key third-party libraries to support the new major. - **Nobody** should plan to move during the final months of their current major's LTS; that leaves no room for a blocked library. A practical rule: every app must be on the current major **within an agreed number of months after its release**, well before the previous major's LTS ends. ## Keeping upgrades small all year 1. **Take every minor and patch promptly.** They are backward-compatible by policy, and staying on the latest minor makes the major hop smaller. 2. **Treat new deprecations as backlog items**, cleared during the current major while both APIs exist. 3. **Run a canary pipeline against `-next` and `-rc` pre-releases** for the most important apps and every shared library, so breaking changes are known before the major ships. 4. **Track runtime prerequisites early.** Each major can raise the TypeScript and Node floors; v22, for example, requires TypeScript 6.0 and no longer supports Node 20. ## Shared libraries are the multiplier A shared library is upgraded once but consumed everywhere, so it carries the strictest rules: - declare **Angular peer dependency ranges** honestly, and widen them to a new major only after testing against it; - keep **developer preview and experimental APIs out** of shared libraries, or behind an internal wrapper, because they can change in any release; - release a version supporting the new major **early**, since every consuming app is blocked on it. ## Making it visible - A dashboard listing every app, its Angular major, and that major's **LTS end date**. - An alert when an app is two majors behind or within a few months of LTS end. - A named owner for the yearly upgrade in every team, not "whoever has time". ## What a strong answer weighs - **Autonomy vs cost**: independent upgrades feel cheaper per team but multiply the library test matrix. - **Freshness vs stability**: moving on day one catches bugs early; waiting for patches and library support lowers risk. - **Enforcement vs trust**: a hard deadline tied to LTS end is simple to audit; softer guidance drifts. The policy is good if, on any given day, the organisation can say which majors it runs, when each one's support ends, and who is upgrading what next.

  • Why does 'within one major of current' guarantee an Angular app stays supported?
    Because since v22 each major gets 24 months of support and a new one ships every 12 months. When a new major arrives, the previous one enters its 12-month LTS, so the current and previous majors are always covered; only two majors back falls outside.
  • How should a shared Angular component library handle a new major when apps upgrade independently?
    Test against the new major early, ideally on its -next and -rc builds, then widen the Angular peer dependency range to cover both the previous and the new major. Keep that range until no consuming app remains on the older major, and avoid developer preview APIs that could break one of them.

saying these in an interview costs you the question

  • Staying two majors behind is safe because LTS covers it.
  • Minor Angular updates can wait until the next major upgrade.
  • Shared libraries can use experimental APIs if the apps pin versions.
  • A monorepo in lockstep never gets blocked by a single team.
  • The upgrade can start when the current major's LTS is almost over.