Angular Finally Slows Down: Why Stretching Major Releases to a Year Is the Right Call
Angular Finally Slows Down: Why Stretching Major Releases to a Year Is the Right Call
My take, upfront: this is one of the best decisions the Angular team has made in years.
If you've spent any real time maintaining large Angular applications in production, you already know the feeling — you close out a year of feature work, look up, and realize Angular has already shipped two major versions while you weren't looking. With the release of Angular 22, the team is finally changing that: major versions now ship every 12 months instead of every 6. Having lived through several enterprise-scale migrations, I think this is a genuinely good move, and I want to explain why.
What actually changed
The updated Angular Versioning and Releases Policy introduces a few concrete shifts, starting with Angular 22:
| Before | Now (from Angular 22) | |
|---|---|---|
| Major releases | Every 6 months | Every 12 months |
| Minor releases per major cycle | 1 to 3 | 4 to 6 |
| Total support window | 18 months | 24 months |
| Active support | 6 months | 12 months |
| LTS support | 12 months | 12 months (unchanged) |
In short: fewer major versions, but each one gets more minor releases feeding into it, and every version stays supported for longer. Active support alone doubles from 6 to 12 months, and the total time a version is supported (active + LTS) goes from 18 to 24 months.
Why this matters if you actually ship Angular apps
On paper, a versioning policy tweak sounds like a formality. In practice, if you work on large, long-lived Angular codebases, this touches your day-to-day life directly.
The old cadence meant two major versions a year. Spend a year building features — which is the normal pace for any non-trivial product — and you'd come out the other side with two major upgrades already waiting for you, on top of whatever you were originally trying to ship. For a small app, that's an afternoon of ng update and moving on. For the kind of codebases I've worked on — thousands of components, years of accumulated architecture, dozens of shared libraries — a major version bump is not a quick pass. It's a project of its own.
And it's not just about touching a lot of files. Angular has been shipping genuinely significant paradigm shifts, not just bumps. Take the resource API becoming stable in Angular 22: it's signal-based, and it's meant to replace the RxJS-observable-driven patterns most of us have used for years to handle data fetching in services. Migrating from observables to resource across a large app isn't a find-and-replace — it's rethinking how every service endpoint is consumed, retested, and reasoned about. That kind of migration takes real time.
Now add the fact that a major upgrade rarely happens in isolation. Big Angular apps lean on third-party libraries — NgRx, PrimeNG, and similar — and those libraries need time to release versions compatible with the new Angular major. So the realistic sequence looks like: Angular ships a major version, you start planning the migration, and while you're still migrating (or waiting on a library to catch up), Angular has already released another major version. You're perpetually behind, chasing a moving target instead of migrating deliberately.
The upside of slowing down
Stretching the major release cycle to a year gives everyone more breathing room:
- Teams get more time to migrate before the next major lands, instead of being sandwiched between two upgrades per year.
- Third-party maintainers get more time to certify compatibility, so you spend less time blocked waiting on an ecosystem library.
- Angular gets more time to stabilize each major version and can bundle more features into a single release instead of spreading them thin across two.
- More minor releases per cycle (4–6 instead of 1–3) means new features and improvements still land at a steady pace — you're not trading velocity for stability, you're decoupling feature delivery from the disruption of a major bump.
Final word
For teams maintaining small apps, this change probably won't register. But if you're maintaining large, long-lived Angular applications — the kind where a major upgrade is a multi-sprint effort, not an afternoon task — this is a welcome change. Going from two major versions a year to one, with a longer support window and more minor releases along the way, means less time spent firefighting upgrades and more time spent actually building. I think Angular got this one right.