I am not sure this is the case with React. If you look through the blog with releases[1], you will find that breaking changes happen not more often than once in three months, that every breaking change is preceded by a deprecation warning in the previous release, and that many changes are automated through codemods.

Facebook has a large and growing React codebase, and they use master version of React. Therefore making migrations easy is in its best interests.

[1]: http://facebook.github.io/react/blog

It's more the case for other packages in the ecosystem (especially when combined together) which is part of what this react change aims to help, I realize. E.g. react-router is something I've had trouble with over time, as one example. Getting hot loading set up also gets trickier with each new project (which I'm sure you have experience with ;) Getting react transform running a month ago between all the version incompatibilities was pretty tricky. Following a chain of deprecated projects is not super easy generally.

I see what you mean but this has no relation to the React release policy. React itself moves with a pace that should be easy to follow.

Community projects like React Router move faster but this is not something the React team can help you with. If you don’t want to keep up with the breaking changes there, you can wait for the project to stabilize. For example, you can use Backbone Router which hasn’t changed for years.

Finally, if you use something as experimental as hot reloading, please expect it to be tricky to set up until it’s part of official React. This is very experimental territory and there is so much work involved in just making it work that making it stable and easy is not a priority yet.