6 ms·

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 wh

by azov 11y ago

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.

danabramov 11y ago
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 http://facebook.github.io/react/blog
- lexicality 11y ago
  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!
  - danabramov 11y ago
    >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.
- Touche 11y ago
  > 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.
  - danabramov 11y ago
    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.
    - madeofpalk 11y ago
      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.
      - 11y ago

by azov 11y ago

danabramov 11y ago

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 http://facebook.github.io/react/blog

lexicality 11y ago
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!
- danabramov 11y ago
  >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.
Touche 11y ago
> 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.
- danabramov 11y ago
  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.
  - madeofpalk 11y ago
    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.
    - 11y ago