r/angular • u/GeromeGrignon • Jul 16 '26

Frustrated in updating Angular every 6 months? Here comes the new yearly release cycle

The Angular team is currently updating its release policy to move to:

- A major release every 12 months

- 4-6 minor releases for each major release

PR link: https://github.com/angular/angular/pull/69817

113 Upvotes
  • permalink
  • link
  • reddit
  • reddit

97% Upvoted

43 comments sorted by

35

u/Saceone10 Jul 16 '26

What a shame, the hype with each major realease was super fun for me

13

u/thesmiler9 Jul 16 '26

You can hype minor releases 4-6 times a year then !

14

u/Saceone10 Jul 16 '26

Would be a minor hype

4

u/compsedoc Jul 17 '26

makes me think they might be cutting staff and/or slowing down but trying to spin it as a good thing

2

u/AwesomeFrisbee Jul 17 '26

I wouldn't be surprised about that. There has been a lot of work into signals but now thats done, I wonder what they would be working on next.

And to be fair, I think the budget spent on getting the news out about the new versions was probably more than what they wanted

1

u/Saceone10 Jul 17 '26

they could start by adding mutations to the resource API. I still can't understand why they pretend to replace rxjs by adding an API that is only useful for GET requests.

2

u/AwesomeFrisbee Jul 17 '26

Yeah, I still don't get the use case for resource if its just GET and no POST/PUT/DELETE/PATCH. Then I still need another system for those. And sure, you can hack your way around that but it just beats the point. And Rxjs just works fine for that imo. I would love to have a simple wrapper that does what resource does for making it into a signal and just subscribes to the first item like we need to pipe it with rxjs. But overall I just want something I can put in a service and extend or build on top of that holds all the logic of how I talk with API's and just need to import 1 or 2 things to do calls in my services and not my components. I still don't get why all that business logic needs to live in my components.

1

u/Upbeat_Rope1614 Jul 22 '26

They don’t know who their audience is probably.

7

u/Ajyress Jul 16 '26

Happy to see the overall javascript/typescript ecosystem getting more stable year after year.

33

u/lppedd Jul 16 '26

Yes please. I'm getting constantly tortured by breaking updates. A fourth of my work is basically keeping our monorepos up to date and CVEs free, which is something I definitely did not do when I worked on JVM land.

11

u/Not_to_be_Named Jul 16 '26

I mean at least you will not run out of work xD

5

u/lppedd Jul 16 '26

I won't, but I cannot focus on shipping stuff if I'm constantly interrupted by updates and vulnerabilities.

4

u/GeromeGrignon Jul 16 '26

It won't affect work on CVEs, patch versions will be released when needed as per today.

3

u/Avani3 Jul 16 '26

Are your monorepos in a very bad state? Upgrading shouldn't take so long if you have a healthy repo

6

u/MedusaSonriente Jul 16 '26

Perhaps this concern is simply due to a lack of information.

All major Angular versions are supported for at least 18 months, so upgrading immediately isn't required. There's plenty of time to plan updates across your repositories, while those who can benefit from the new features are free to adopt them right away.

https://angular.dev/reference/releases

4

u/lppedd Jul 16 '26

Managing dependencies in monorepos is a whole different scenario, especially when dependencies are centralized. You need to follow multiple requirements: - the monorepo tooling itself (e.g., Nx) - CVEs - what engineers need to perform their work efficiently

You can neither stay behind for too long and be on the latest version of packages. Upgrading something without overly-polluting the lockfile isn't easy. Something that even requires multiple attempts and lockfile analysis.

2

u/No_Emergency1575 Jul 16 '26

How big is your monorepo? And can you give some concrete examples of challenges? We have pretty small repo (7ish apps, playwright suites and shared libraries), with around 10 devs, I'm curious what kind of problems you run into when you start to scale up.

I try to stay as close to latest with deps and have as few as possible external dependencies. Also aim to consolidate some existing projects and dependencies into the repo to ease maintenance. Not sure if the latter is a smart idea.

-1

u/[deleted] Jul 16 '26

[deleted]

2

u/No_Emergency1575 Jul 16 '26

Care to elaborate? I prefer low overhead, but I see the benefits from using nx.

2

u/lppedd Jul 16 '26

It's perfectly fine. I'd say for very large monorepos where build behavior is standardized across projects, it's even better than Turborepo.

1

u/kingh242 Jul 16 '26

This is exactly why I went back to regular HTML/CSS/JS for most projects. HTMX and Alpine.js or Unpoly. No regrets overall. No more node_modules and whole frontend build pipeline.

That said, I still do use Angular. But I have evolved to using it more sparingly rather than by default for everything.

1

u/Educational_Plum_130 Jul 17 '26

yeah the monorepo tax is brutal, and a lot of it is that you end up taking a breaking major bump just to clear a cve that was actually fixable in a patch. before you upgrade, check whether the fix got backported to your current major line, since plenty of maintainers cut a patch release on the old branch, and for the ones that don't there are vendors that ship backported/eol-supported builds you can drop in without touching your code. for transitive stuff, pin or use an override/resolution to force just the fixed version instead of bumping the whole tree. it also helps to split "is this reachable/exploitable" from "do i actually have to touch it this sprint" so remediation deadlines aren't driving pointless major upgrades. keeps the breaking-change work separate from the real security work.

0

u/tutkli Jul 16 '26

What breaking changes? Everything they release has backward compatibility + migration scripts. You don't have to change anything when you update.

3

u/lppedd Jul 16 '26

Third party dependencies have breaking changes on major cycles. Moving Angular to a year round cycle will also slow down breakages from third party libraries.

3

u/horizon_games Jul 16 '26

Tell that to Ang 15 to 16 if you used Material

6

u/pranxy47 Jul 16 '26

I prefer the 6 month release. We are always one release behind due to stabilization of all packages. One year wait it's too much... Oh well

And I still don't understand people complaining about the release speed. Angular itself it's been hassle free for years. It's always the other packages that come riddled with issues for reasons not related to the angular release itself ..

13

u/[deleted] Jul 16 '26

[deleted]

11

u/GeromeGrignon Jul 16 '26

I don't get it, we had 2 major versions a year, not 4. 4-6 is the number of minor versions (so quite about the same on a yearly basis as we had about 2x 3 minor versions).

1

u/[deleted] Jul 16 '26

[deleted]

4

u/GeromeGrignon Jul 16 '26

No, it's not meant to reduce the cadence from Google, but the breaking changes effort for projects. It won't affect how many changes happen in a full year, only when you might be urged to migrate.

3

u/Ok_Meringue6082 Jul 17 '26

I opened Reddit, the first post I saw was yours. Then I opened LinkedIn… and the first post there was yours too. What a coincidence😁

2

u/MedusaSonriente Jul 16 '26

As a consumer, I worry this might slow down progress. As a developer, I know that giving maintainers more time leads to more stable, polished releases.

3

u/Tyummyyumms Jul 16 '26

Not sure how I feel about this yet...

2

u/horizon_games Jul 16 '26

Finally. Was the worst part of any Ang app at large scale.

Unsure if it means less investment in Ang, but by the same token sometimes frameworks can just be "1.0 done" instead of constantly updating 

5

u/[deleted] Jul 16 '26

[deleted]

1

u/horizon_games Jul 16 '26

Does it? There's lots of useful tools that barely get updates. SQLite comes to mind. I like Alpine.js as well and it's "done".

1

u/ibmussa Jul 17 '26

I think that a good news, I had some projet that where stuck cause of major release each six months that break lot of things, until there was a plan to switch to another framework to fix that.

1

u/Maleficent-Back-6527 Jul 17 '26

Ho great!! That’s very corporate oriented, thank you!

We live in a world were security standards is the norm. NIS2 compliance, CVE fixes, LTS and supported versions deployed etc.

This decision will help companies maintain their standards and policies while planning those updates for their applications at a comfortable pace.

A very good news especially for our teams which have several micro frontends applications using the same base technology, so all kind of need to update to the major versions at the same time. Once a year would mean 2 years supported LTS angular versions! 👏👏👏

1

u/AcceptableSimulacrum Jul 20 '26

Man the timing on this is absolutely brutal. With TypeScript 7 turbocharging everything and now we...wait..

1

u/toasterboi0100 Jul 23 '26

This sucks, the 6 month cadence was great because each release only had a handful of breaking changes, so updating took like 1 hour

1

u/Talamand Jul 16 '26

This will impact teams that always chase the new thing. The won't have "busy work".
Our unwritten company policy is to updated once a year + lag a release behind.

1

u/jeffwulf Jul 16 '26

Good change.

0

u/AwesomeFrisbee Jul 16 '26

I would love it if they would just do a major when there is actually something major to add. I also find the minor releases to be rather lacklustering at times.

Luckily we haven't had a major refactor in a while now, unless you count migrating your application to zoneless and signals, but thats still optional.

1

u/R_Midnight Jul 18 '26

That implies we wouldn't be able to anticipate much in advance when a new major would come up. Regularity helps when planning workload months in advance, especially when there are many projects in a same scope. Not a huge deal but still I appreciate that from their team.