docs: add v23 release and change to yearly release cycle - #69817
Conversation
## Summary This PR adds v22.x and v23 release dates. It also changes Angular's release cadence to a yearly cycle. ## Why we are making this change The community has long requested less frequent major releases due to the impact of breaking changes and upgrades for their projects as well as for enterprise customers. Additionally, a longer release cycle provides increased API stability for developers using agentic workflows, while still delivering a reasonable cadence of API upgrades and migrations.
|
Deployed adev-preview for 37afb54 to: https://ng-dev-previews-fw--pr-angular-angular-69817-adev-prev-9womvemj.web.app Note: As new commits are pushed to this pull request, this link is updated after the preview is rebuilt. |
|
Does it imply that you will still introduce experimental and/or development previews in minor releases? Before the advent of the LLM era, upgrading to Angular鈥檚 latest version was already quite straightforward. Now, it鈥檚 easier than ever. |
|
I feel like this change is more like for AI's be able to reach the knowledge of the current version more than the developers/mantainers. If the new major version requires alot of breaking changes will this not cause that frameworks that build on angular to take twice as much more time to adapt to the new version? I hope this does not becomes the fiasco of .net framework being a torture to update from a version to another just because each version are just to many breaking changes. |
Major releases were really only meant to introduce breaking changes. Minor release were already used to introduced new features (stable or experimental/dev preview). |
|
Recent major upgrades have been genuinely painless - less because of cadence and more because of the automatic migration schematics and the deprecation policy spreading changes across releases. So the upgrade-burden rationale alone wouldn't obviously justify this change. One thing the announcement leaves open: should the slower major cadence be read as a signal about the level of investment in Angular going forward, or is team capacity unchanged and this purely about reducing ecosystem churn? Given the stated rationale explicitly targets agentic workflows and the AI ecosystem moves on a monthly cadence, sustained feature velocity in minors (e.g. iteration on experimental features like WebMCP) matters more than ever - so an explicit statement on investment would help teams making long-term framework bets. edit: updated, as question was partly answered already. |
|
Part of me wishes we'd waited for v29 in late 2029 to align Angular versions with the calendar year. |
|
Perfectly confirms my previous point. I used to be an assistant developer for Angular, but now I am very disappointed in Angular, and I can feel that you have lost the passion to maintain this project. |
|
You should definitely label the next major by the year it's released in, even if you jump a couple majors. |
It's totally fine to be disappointed with changes. But I think it's unfair to say that the passion is lost. The Angular team is doing a great job. Amazing features are being shipped all the time. And also there are many community PRs coming in every single day. So I think the passion for sure is here. Besides, Angular is used in 3000+ Google apps such as Gemini and Google Fonts so I think Angular project will be maintained 馃榿 |
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
|
I'd like to remind commenters that the https://github.com/angular/angular/blob/main/CODE_OF_CONDUCT.md applies here. Thank you. |
|
It would be nice to have the major version coincide with the current year |
|
It would be great to see fewer breaking changes in patch versions as well. I鈥檝e had a lot of issues with SSR breaking in v20 with patch updates. It may be our codebase but the upgrade schematic has never worked for me. I always have to do it by hand. |
Those were all related to important security fixes. |
After v23 released |
|
I am very much in favor of a yearly cadence. It has been difficult for us to keep up. |
|
Apple's yearly naming convention definitely made it easier to remember the current version. Just don't forget which year we're in 馃槃 and voil脿, you'd know what the latest version is. I hope it will possible for us too. |
|
Hello. I don't think switching to a yearly release will help with stability. The current, well past model, allowed us to agree on an api over shorter releases. This now means we have to solve/argue about a public api over 1 year without votes. I strongly object against the model suggested here, and i believe we should stick with the 6 month release model. Edit; I don't care about version numbers, and i do not care when branches are merged in. What i care about is a stable release schedule. |
|
I look forward to the arrival of selectorless every day. |
|
I still believe this to be a mistake, and us who are using lts only builds will have less of a say over how the api evolves. Just my 2 cents. |
Summary
This PR adds v22.x and v23 release dates. It also changes Angular's release cadence to a yearly cycle.
Why we are making this change
The community has long requested less frequent major releases due to the impact of breaking changes and upgrades for their projects as well as for enterprise customers. Additionally, a longer release cycle provides increased API stability for developers using agentic workflows, while still delivering a reasonable cadence of API upgrades and migrations.
This PR will not affect how features are released in general, features can and will continue to be shipped in minor versions. Only breaking changes are restricted to major versions.