Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
RFC 6: Deprecate unsafe lifecycles #12028
Proposed Release Plan
The minor version numbers for 16 are just examples. The main point is to note that we plan to release this change over two minor updates, to give libraries a chance to update without noisy deprecation warnings.
Differences from RFC
This proposal differs from the original RFC in a couple of ways. I have updated the RFC to reflect these changes, but they are also listed below:
Follow Up Work
Ya! I know we talk about this on every depreciation but...this will affect every react component, releasing on a minor means CI is going to break for folks and the burden to fix quickly will be on lib maintainers unless they want to deal with a flood of issues about the depreciation warnings. The most graceful approach for maintainers would be to deprecate in 17 and remove in 18
We do talk about this every time. :-)
Last time we settled on making those warnings yellow rather than red. It is up to you to decide whether
In this case we also plan to not include the deprecations in the first minor, give time to major libraries to update without noise, and later enable them. (As written in the RFC)
I don't think what you propose is feasible. We can't stretch this work into two years. (And our release cycle is roughly yearly.)
Yeah sorry, I don't mean to keep rehashing this, during the v15 deprecation we also said the goal was to try and have faster major release cycles post v16 so we weren't waiting two years rm warnings, did that plan get squashed?
Again, respectfully, I'm sorry to rehash but I also feel the result of this as a maintainer of many react things and it's the most unpleasant part of working in the React OSS ecosystem for me
I totally understand that.
I think an important thing to consider here is the incentives. I don't think we can just tell people to update their component, and not get something in return in the next major. It feels like empty effort.
Even if we released majors faster, React 17-that-just-deprecates-some-methods wouldn’t be an exciting upgrade. We haven’t been in this situation before because every major release of React included significant improvements and/or new capabilities that made the migration worth it.
If React 17 is not appealing on its own merits, we risk fragmenting the ecosystem where a much higher percentage of people decides not to upgrade and wait out until making those changes is truly worth it. And at that point you have pretty much the same situation as now, except that there was an extra churning major release in the middle.
Unfortunately pretty much all of the things that we’re working on to make React 17 exciting need those changes. And we need to start this migration as early as we can because we know those hooks are problematic and get in the way.
Of course we could call the upcoming 16.3 a “17.0”. But I don’t see the point. The projects using 16 today will keep working. If it’s just about CIs, again, this is completely avoidable and depends on your CI setup. If it’s about the migration cost, we understand it but don’t see a way to avoid it.
Yeah, @jamsch. That was mentioned in the RFC, but here is a more complete example in a blog post I'm working on: