Comment by rdsubhas | Hacker News Reader

Comment by rdsubhas | Hacker News Reader

This goes directly against their own versioning policy of abusing cliffs and bringing everyone along: https://reactjs.org/blog/2016/02/19/new-versioning-scheme.ht...

Quoting from that page:

> Therefore it is important that we don’t just upgrade our own codebases but that we bring our whole community with us. We take the upgrade path very seriously - for everyone.

> If we’re not careful, we can hit a cliff where nobody upgrades. This has happened to many software project ecosystems in the past.

> Therefore, we’re committed to making it easy for most components and libraries built on top of React to be compatible with two major versions at the same time.

I'm not sure if I'm reading them and the diagrams in that page correctly, but looks like the deprecation should happen at 17 and removal at 18 according to it?

> Minor revision releases will include deprecation warnings and tips for how to upgrade an API or pattern that will be removed or changed in the future.

16.3 is including dep warnings and tips to upgrade, check.

> We will continue to release codemods for common patterns to make automatic upgrades of your codebase easier.

Probably will be there closer to 17 release.

> Once we’ve reached the end of life for a particular major version, we’ll release a new major version where all deprecated APIs have been remove

Once 16.x end of life is reached, the next major version, 17, will remove the deprecated APIs, check.

They are literally following exactly what they said.

Note 16.3 doesn’t even include warnings. We are only adding support for the new aliases at this point, but won't fire warnings until the biggest ecosystem libraries have updated with recommendations in the blog post.

Yes, there will also be a codemod for the "UNSAFE_" rename.

One of the main focuses of 16.3 is to enable open source libraries to update their code in advance of deprecation warnings. (We're trying to go one step beyond SEMVER- so that application developers don't have to be bothered by warnings in third party code that they can't change.)

And the codemod has already been released: https://github.com/reactjs/react-codemod#rename-unsafe-lifec...

We've used it internally (at Facebook) to update ~14,000 components already, so it's well tested.

Reply on news.ycombinator.com