4 ms·

Surprised they didn't start at 1.0. I understand what they're saying with the reasoning, but I don't think I agree with it. Not that it really matters, I guess

Surprised they didn't start at 1.0. I understand what they're saying with the reasoning, but I don't think I agree with it. Not that it really matters, I guess.

spicyj 11y ago
People already say "React 13" and "React 14" colloquially so we figured calling this one 15.0 would cause the least confusion in the long run.
- Zarel 11y ago
  Didn't Java do a similar thing, where they renamed Java 1.5 to Java 5?
  - chrisseaton 11y ago
    That used to be a marketing thing and the engineering version was always 1.x, but starting with 9 or 10 can't remember which it's going to be x.0.
    - cpeterso 11y ago
      Sun did the same thing with Solaris, jumping from version 2.6 to 7.
bryanlarsen 11y ago
15 sets the right impression. Because it's high, it implies that it's changed 14 times already, and will probably do so again in the future. I've been burned badly before by breaking API changes in patch releases. (Rails 2.4.5). If you're not afraid of bumping the major number on even a minor API change, then it makes it more likely that you will actually do so rather than paying lip service to the idea of semver.
- 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.

Surprised they didn't start at 1.0. I understand what they're saying with the reasoning, but I don't think I agree with it. Not that it really matters, I guess.

spicyj 11y ago

People already say "React 13" and "React 14" colloquially so we figured calling this one 15.0 would cause the least confusion in the long run.

Zarel 11y ago
Didn't Java do a similar thing, where they renamed Java 1.5 to Java 5?
- chrisseaton 11y ago
  That used to be a marketing thing and the engineering version was always 1.x, but starting with 9 or 10 can't remember which it's going to be x.0.
  - cpeterso 11y ago
    Sun did the same thing with Solaris, jumping from version 2.6 to 7.

bryanlarsen 11y ago

15 sets the right impression. Because it's high, it implies that it's changed 14 times already, and will probably do so again in the future. I've been burned badly before by breaking API changes in patch releases. (Rails 2.4.5). If you're not afraid of bumping the major number on even a minor API change, then it makes it more likely that you will actually do so rather than paying lip service to the idea of semver.

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.