Gives the opposite impression to me. If I see a component using semver at version 15.x I'd assume it's very unstable (unless it's very old).

So, contrary to what spicyj is saying, to me it seems to create the most confusion in the long run at the expense of addressing some short-term concerns ("people already call it React 14"). I'd much prefer they switched to 1.0.

You might want to take a look at the blog documenting the releases[1]. Breaking changes happen, but not more often than once in three months. Every breaking change is preceded by a deprecation warning in the previous release, and many changes are automated through codemods. And of course the API surface area is small which is why it’s possible to move fast without breaking things.

Don’t forget Facebook has a large React codebase so it cares very much about automating migrations.

If React switched to 1.0, with some breaking changes every three months, it would be 14.0 again in a couple of years. Then googling for tutorials would get confusing. Why not do that now?

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

I would not describe a breaking change every three months as stable.

I like the upgrade paths but can you really say with a straight face that an API is stable if the code you write could be invalid a few months later? That's a maintenance nightmare!

>That's a maintenance nightmare!

Are you using React? I’m curious if this is your feedback on the pace of changes, or if this is just a guess.

In reality React API surface area is pretty small so most changes are automated by codemods. Codemods are programs that modify your source code. They work pretty well because Facebook uses them on a large scale.

Not everything is covered by codemods but generally the feeling I get from talking to the community is that React moves at an acceptable rate, and changes take about a day to apply once a three months for most apps. Deprecation warnings also give you several months to fix use cases that will be unsupported in the next version.

In return, this allows React to become a better library and not stagnate. I see your point in theory but please talk to the people using React, and you might find that it is not a problem in practice.

> Breaking changes happen, but not more often than once in three months.

Once every 3 months is too frequent. Imagine curl broke compatibility every 3 months and you had to relearn curl. How terrible! I'm pretty sure you'd use something else after a while.

I'm not saying React should be as stable as curl, but it should be striving to become that. The JavaScript community loves to have these eternally evolving libraries that are never actually stable and that's not good for anyone. You should have a long term plan that says "we still don't know what this library should be, but within 2 years we should have it figured out". In reality it feels like JS libs only become stable after they've been abandoned.

Are you using React and voicing your concern? Or are you making a guess?

Every three months might be too often for a tool like curl. In case of React, the community seems to be happy with the tradeoff between moving forward and keeping the old code working.

You might want to ask a few people who use React to draw the conclusions. I talk to a lot of people in the React ecosystem, and so far the feedback I heard is that updating React has been the least of their worries, compared to some other libraries in the ecosystem which are far less stable.

Personally, I updated a fairly large (~1000 modules) app from React 0.11, to 0.12, to 0.13. After the ecosystem catches up and libraries release compatible updates (if they need to), it always took less than a day to upgrade. Doesn’t seem like a big price to pay for avoiding stagnation and actually improving the library.

And I wasn’t even using codemods which React team ships (and widely uses internally at Facebook). Codemods just convert your code through most of the API changes automatically.

> Are you using React and voicing your concern?

Yes.

> Every three months might be too often for a tool like curl.

Why should a tool for creating dynamic HTML be held to a lesser standard? I wouldn't expect the level of stability that curl has yet, but I would expect it to be an eventual goal of the project. The reason why we build abstractions is so we can eventually stop worrying about a problem; that can't happen without stability.

> You might want to ask a few people who use React to draw the conclusions. I talk to a lot of people in the React ecosystem, and so far the feedback I heard is that updating React has been the least of their worries, compared to some other libraries in the ecosystem which are far less stable.

That's because you talk to other enthusiasts who are happy about changes. Try asking people outside of the React Slack channel for a wider perspective.

I've had people complain on my projects about upgrading apps using APIs deprecated 2 or 3 years prior. And I feel genuinely bad about it, because if they are having to justify spending 3 or 4 days refactoring their app (which is hard to do in a lot of companies) because I made an API mistake 3 years ago... I feel bad about it. We should strive for better stability.

Thank you for your feedback. Would you please name specific API changes in React that were problematic and forced you to spend more than a day migrating? This would help me better understand the issues.

But HTML/Javscript is a moving target in itself. HTTP moves slower. So an HTML library is by it's nature going to have to move faster than an HTTP library.

You also have the ability you like, you know, not upgrade. Of course you might miss out on some of the newer and fancy features that come with the upgrades, but you still always have control.

If React 15 was good enough for you when you started using it, it doesn't necessarily fundamentally stop working when React 16 ships.

>If React 15 was good enough for you when you started using it, it doesn't necessarily fundamentally stop working when React 16 ships.

No, but your project is seldom 100% finished either. So as you do minor changes to it, and want to use some new lib, you find out that it's not compatible with your old version.

And libraries stop get maintained too -- and when you finally try to make the conversion it will be harder the longer you have waited, because aside from porting your code to all new React stuff, you'll also need to find replacement for all those libs at once (not piecemeal, which would be the case if you kept the project up to date faster).

This could also happen for all kinds of external reasons too -- e.g. you use a third party service and they change their API. Or you update your OS and your old libs suddenly stops working. Or a browser deprecates some feature (like Object.observe that Google warns that it will be removed on March).