As stated in the post, the breaking changes are intentionally minimal. For example, we haven't removed any of the APIs that were originally slated to be removed in 17.

This is actually amazing, by making the next release with only breaking changes, and without new features, devs can focus strictly on what needs to be fixed.

Allowing code to be properly ready and tuned for the next major release. Where the new features will be actually introduced, hopefully, without new bugs.

I think the marketing line of "No new features" could lure people into a false sense of security on this upgrade, even if the breaking changes are minimal.

By all means make breaking changes, just maybe tone down the marketing.

How is a very elaborate blog post indicating the what & why considered marketing?

In my opinion this goes WAY beyond the usual changelog entry in other repositories.

Don't get me wrong, this is great documentation, very high quality, and well done to the React team for a great release and what I think is a solid decision around what to include and what not to include in this release.

I think it's important to understand though that React is _marketed_, and unfortunately for many a name as clearly stated as this will likely define their expectations significantly. This could be especially pronounced for those who are less proficient in English.

So what? That's how semantic versioning works, it wouldn't be a major point release without the breaking changes.

I was pointing it out because people might misunderstand "no new features" as there being no change that they need to be aware of (e.g. internal restructuring).

The breaking changes don't seem to effect all that much. I for one don't see it being that breaking.

to be fair one changes bites me aswell, but I always new everything is "async" in react functional components and I've often needed to write stuff to get around that. but effect cleanups are different and I just did not care.