Since Angular v22, how often does a new major version ship, and how long is each major supported?
answer
- yearly rhythm, not twice a year
- two support stages per major
- active first, then long-term
- second stage: critical and security fixes
basics
~20 sSince v22 Angular ships a major roughly every 12 months, with 4-6 minors in between. Each major is supported for about 24 months: 12 months active, then 12 months of LTS that only takes critical and security fixes.
solid answer
~40 sAngular uses semantic versioning. Since v22 the team targets **one major every 12 months**, **4-6 minors per major**, and a patch or pre-release (`-next`, `-rc`) almost every week; until v22 majors came every 6 months with 1-3 minors. Each major is typically supported for **24 months** in two stages: 12 months of **active** support with regular updates and patches, then 12 months of **long-term support (LTS)**, which only receives fixes for new security vulnerabilities and for regressions caused by third-party changes such as a new browser version. In the v22.2 support table, v22 (released 2026-06-03) is active until 2027-06 and in LTS until 2028-06, v21 and v20 are in LTS, and v2 to v19 are unsupported. The next major, v23, is scheduled for around June 2027.
go deeper
Recall the numbers: a major every 12 months since v22, 24 months of support split into 12 active and 12 LTS, and that minors and patches are safe to take.
Explain what each stage delivers, especially what an LTS fix is, and why older sources say six-month majors: that was the cadence until v22.
Turn the table into dates for your own app: which major you are on, when its LTS ends, and when the next upgrade has to be finished.
Frame the cadence as a yearly upgrade budget for every team, and decide how close to the LTS end date the organisation is willing to run.
Angular publishes its release rhythm and support windows on the **versioning and releases** page of angular.dev. Knowing them is what lets a team say, with dates, whether the version it runs still receives security patches and when the next upgrade has to happen. ## Semantic versioning in Angular An Angular version number has three parts, `major.minor.patch`, and each part signals how much work an update may need: | Level | What it may contain | Work expected from you | | :-- | :-- | :-- | | **Major** | Significant new features and breaking changes, such as removed APIs or changed timing | Run the update scripts, refactor, re-test, learn new APIs | | **Minor** | Smaller new features, fully backward-compatible; peer dependency ranges only widen | None required; adopt new APIs when you want | | **Patch** | Low-risk bug fixes | None | Two pre-release tags let you try what is coming: `-next` (still under active development, for example `8.1.0-next.0`) and `-rc` (release candidate, feature complete and in final testing). The `@angular/core` packages and the Angular CLI you run must share the same major version. ## The release rhythm since v22 The published expectation for each cycle is: - **one major release every 12 months**; - **4-6 minor releases** for each major; - **a patch release and a pre-release build almost every week**. **Before v22** the cycle was a major every **6 months** with **1-3 minors** each. That is why older blog posts and interview answers still say "Angular releases twice a year": it was true for most of Angular's history, and it stopped being true with v22. The v22 schedule lists 22.1 (late July 2026), 22.2 (September 2026), 22.3, 22.4 and 22.5 through March 2027, then **v23.0 around June 2027**. The docs describe all such dates as general guidance that can change. ## The support window A major is typically supported for **24 months**, split into two equal stages: | Stage | Length | What ships | | :-- | :-- | :-- | | **Active** | 12 months | Regularly scheduled updates and patches | | **Long-term support (LTS)** | 12 months | Only critical fixes and security patches | An **LTS fix** is considered only when it resolves one of two things: 1. a newly identified **security vulnerability**; or 2. a **regression since the start of LTS caused by a third-party change**, such as a new browser version. Ordinary bugs you find in an LTS major are fixed, if at all, in the current major; they are not backported. LTS keeps a version safe to run while you plan the move; it does not keep it improving. ## Reading the current support table The v22.2 docs list three supported majors: | Version | Status | Released | Active ends | LTS ends | | :-- | :-- | :-- | :-- | :-- | | ^22.0.0 | Active | 2026-06-03 | 2027-06 | 2028-06 | | ^21.0.0 | LTS | 2025-11-19 | 2026-06-03 | 2027-06 | | ^20.0.0 | LTS | 2025-05-28 | 2025-11-19 | 2026-11-28 | Versions **v2 to v19 are no longer supported**. Two details are worth noticing: - **v20 and v21 were released under the old six-month rhythm.** Their active stage lasted only until the next major shipped, roughly 6 months, followed by about 12 months of LTS, so roughly 18 months in total. - **Three majors overlap right now** because of the transition. Once the 12-month rhythm settles, the current major is active and the previous one is in LTS: two supported majors at any time. ## What this means for planning 1. **Budget one major upgrade per year.** With a 12-month cadence, staying current costs one major hop a year, usually scheduled after the new major's first patches. 2. **Treat the LTS end date as a deadline, not a target.** After it, a newly found vulnerability in that major gets no patch. 3. **Take minors and patches freely.** They are backward-compatible by policy, so falling behind on them buys nothing. 4. **Track two majors, not one.** Anything more than one major behind the current release is at, or close to, the edge of support. A common mistake is to treat LTS as "supported, so fine": an app on an LTS major runs, but it receives no new features and no ordinary bug fixes, and the clock to its end date is already running.
- What qualifies as a fix for an Angular major that is in LTS?Only two kinds: a fix for a newly identified security vulnerability, or for a regression that appeared since LTS began and was caused by a third-party change, such as a new browser version. Ordinary bugs and new features go into the current major only, so an LTS major is safe to run but no longer improves.
- Can an Angular minor release force you to upgrade TypeScript or another peer dependency?No. Minors are fully backward-compatible and only widen peer dependency ranges; npm dependency updates that require changes in your app happen only in a major. The compatibility table shows this: 20.0.x accepted TypeScript >=5.8 <5.9, and 20.2.x widened it to >=5.8 <6.0, so TypeScript 5.9 became optional, not required.
- Why do three Angular majors show as supported in September 2026 if each is supported for 24 months?Because v20 and v21 were released under the old six-month cadence. Each got about 6 months active and 12 months LTS, and their windows still overlap with v22. Once the 12-month rhythm settles, only the current major (active) and the previous one (LTS) are supported at any time.
saying these in an interview costs you the question
- Angular still ships a new major version every six months.
- LTS versions keep getting new features and ordinary bug fixes.
- Once a major leaves active support it receives no fixes at all.
- Minor Angular releases can contain breaking changes that need migrations.
- Any Angular version keeps getting security patches as long as it still builds.