The Six-Year Rewrite: A Map from v15 to v22 In short: Angular changed a lot between 2022 and 2026. This lesson gives you the map, so the rest of the course makes sense. Angular puts out a new big version every six months. Between November 2022 and June 2026, that meant eight new versions. If you open an old Angular project and a new one side by side, they barely look like the same framework. Different files. Different template code. Different way of handling data. Different way of testing. Reading the release notes one by one is a bad way to learn this. They are written for people who were already using the version before. What you need first is a map. The versions, and what each one is known for Version Came out What people remember it for --- --- --- 15 Nov 2022 Standalone components became safe to use. Route guards could be plain functions. 16 May 2023 First look at signals. . Inputs you must pass. 17 Nov 2023 New template blocks ( , , ). . A much faster build. 18 May 2024 Those template blocks became final. First look at running without Zone.js. 19 Nov 2024 Standalone became the default . , . 20 May 2025 Signals became final . . Old marked as going away. 21 Nov 2025 Signal Forms (early version). No Zone.js for new apps. Vitest replaced Karma. 22 Jun 2026 OnPush became the default. Signal Forms became final. , . Two things stand out when you see it laid out like this. Big ideas took three versions, not one Signals showed up in v16, got their full component API in v19, became final in v20, and became the base for forms in v21 and v22. Standalone was optional in v15, the default for new files in v17, and the language default in v19. Nothing arrived finished. This matters in a practical way. A blog post about signals from 2023 describes an API that no longer exists in that shape. A guide to going Zone.js-free from 2024 uses a function with a different name. When you search for Angular help online right now, check the date first. It matters more than it does for most other frameworks. Three changes can actually break a running app v20 marked the old template directives as going away. , , and still work. "Going away" is not "gone." This one is low risk and a tool does it for you. v21 made new apps run without Zone.js. Existing apps keep Zone.js when you upgrade. Nothing changes behind your back. But any code that relied on Zone.js noticing a will need a small change when you do make the switch. v22 made the default. This is the one to pay attention to. A component that does not pick a strategy now gets instead of the old "check everything" behaviour. The upgrade tool protects you. It writes the old behaviour — now called — onto every component you already have. So upgrading is safe. But every new component you write after that is . If your team still thinks "Angular checks everything, so changing a value just works," you will write components that do not update, and nothing will tell you why. Where is your own project? The number in your is the least useful answer. What really decides how much work an upgrade is: how many of the big changes you have already taken on. Four questions you can answer in a minute: A project with 200 modules, 800 s, no signals, and no update strategy anywhere is really still on v15 — even if says 19. That is the honest starting point, and it predicts the work far better than a version number. How this course uses the map The chapters that follow do not go version by version. Nobody adopts things that way. They go one big change at a time: structure, then dependency injection, then templates, then signals, then update strategy, then forms, then delivery and tools. Inside each one, the pattern is always the same: 1. Here is the old way 2. Here is why it started to hurt 3. Here is the new way 4. Here is what to do with the code you already have The architect's view If you are starting fresh on v22 , none of this history is technical debt you have to carry. Write standalone components, put state in signals, leave change detection alone (it is already ), and use Signal Forms. The rest of this course explains why those are the defaults, which matters when you have to justify a decision or debug something that does not behave as expected. If you are migrating , the map above is a planning tool, and the honest starting point is those four commands rather than your version number. A team that reports "we are on Angular 19" has told you almost nothing. A team that reports "200 modules, 800 s, no signals" has told you the size of the job. The most common planning mistake is treating the upgrade as a version-number problem. Bumping through the versions is the fast, visible part, and it is also the part that delivers the least. A codebase on v22 that still uses modules, old template syntax, and no signals has paid the upgrade cost and received almost none of the benefit — and it is now harder to justify further investment, because "we already upgraded." Sequence the structural work as its own e…