4 ms·

Only after a 1.0 release. 0.x implies that breaking changes are always possible My experience has been that the React team provides plenty of advance warning w

Only after a 1.0 release. 0.x implies that breaking changes are always possible My experience has been that the React team provides plenty of advance warning with deprecation notices, similar to the experience of others I've never really been caught out by anything The worst case I've dealt with is bringing an app from .12 to .13 after not touching the code for five or six months. It only took me a few hours to bring everything up to date.

Touche 11y ago
> Only after a 1.0 release. 0.x implies that breaking changes are always possible Yes, which is why so many projects never reach 1.0. There are basically 2 types: 1. Those who don't want to have to care about compatibility at all. 2. Those who care about compatibility a little bit but don't want a large version number. React seems to fall into #2 here. They want a small version number and the perception of stability. But in reality there have been 14 breaking changes, this is version 14 software. It's easier to convince someone to upgrade from 0.13 to 0.14 than it is 1.0 to 2.0 even though breaking changes are just as likely in the former. But the latter has a graver perception.
- danabramov 11y ago
  >2. Those who care about compatibility a little bit but don't want a large version number. >React seems to fall into #2 here. Seriously, a library that goes out of its way to provide useful deprecation warnings and always keeping deprecated behavior for a version, with versions coming out once in three months, and released with codemods automating the transition for you, cares a little about compatibility? React team will eventually jump to bumping major, and it's a good question to ask, but it's a good question to ask the team instead of guessing what and why they do. https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning
  - Touche 11y ago
    > cares a little about compatibility? Yes, they care. But they care more about their ability to make breaking changes without the stench of a major version bump. You have to ask, why is it currently not 1.0? The roadmap you linked doesn't mention it. There's a reason. So what is it? By the way, I know you're a huge React cheerleader and that's fine, and you think I'm being critical of React here and you need to defend this. But I'm not, this is a problem throughout the JavaScript community and really the fault lies there, not with any one particular project which is doing something a lot of others are also doing.
    - clessg 11y ago
      > But they care more about their ability to make breaking changes without the stench of a major version bump. Source?
    - Gigablah 11y ago
      > But I'm not, this is a problem throughout the JavaScript community and really the fault lies there Did you see the complaints when Node went from 0.12 to 4.0?
  - Silhouette 11y ago
    Seriously, a library that goes out of its way to provide useful deprecation warnings and always keeping deprecated behavior for a version, with versions coming out once in three months, and released with codemods automating the transition for you, cares a little about compatibility? Yes, any library that breaks code written according to documented good practices less than six months earlier only cares a little about compatibility. Everything else you mentioned may be true, but it's also mostly irrelevant. This isn't necessarily a criticism of the React team. As I mentioned in another post, it's not as if they're advertising more compatibility than this and then not living up to what they claimed. The problem is some people having unrealistic expectations and reading more into the high profile of React than they should. But mere months between fundamental breaking changes in published interfaces isn't a good level of stability and longevity for most production projects, and for any of those projects that don't have realistic plans and resources available for maintaining the integration regularly, React isn't ready yet.
    - tracker1 11y ago
      Most breaking changes are including warnings 2 versions ahead of time... In TFA they outlined, iirc, 2 changes that would have less time than this. This isn't a magical, final interface we're dealing with... it's iterative changes over time. TBH, I don't like getting stuck at one point.. in practice those using React have been embracing the one-way flow that flux-like frameworks bring... This has been distilled down to Redux (imo, the best workflow option for React), which has signalled some distillation in terms of the interfaces React exposes. This is combined with different rendering paths coming to light, and I think it's pretty great. I'm currently working in an environment that is transitioning from the old-way, to a more current way of doing things. I've been working with node since pretty early on (0.4) and was following it before that. The more I've embraced this continuously updating workflow, the less friction I've experienced as a whole. That doesn't mean no pain, just less of it overall. The React/Facebook guys have been very good members in this larger community, and I applaud them for their efforts... Dropping their own render in favor of Babel, and reducing some of their mutation enablers only show them to be working with feedback from the community. It may be at a pace that's harder to keep up with, but that doesn't mean that they shouldn't be doing it.
    - 11y ago
draw_down 11y ago
> Only after a 1.0 release. 0.x implies that breaking changes are always possible Oh, I didn't know that, it's unfortunate. IMO, just bump major version every time compat breaks. Otherwise projects end up mincing around forever trying to decide when the shiny 1.0 ribbon can be affixed.
- Touche 11y ago
  > IMO, just bump major version every time compat breaks. Some projects do this but most do not. The reason is that if you're using a project that's on version 3 and 6 months from now it's on version 12 that's going to make you think twice about using it. No one wants to go through upgrade pains constantly. The "hack" is to never go 1.0 to hide how often you are really breaking APIs. In reality breaking APIs should be a big freaking deal. You shouldn't do it often. You shouldn't do it just because you realized some other API might be slightly nicer. Once the shine wears off people want stability.
  - tracker1 11y ago
    I think pre 1.0 should represent that breaking changes are happening more often.. a 3-month release cycle with breaking changes in pretty much every stable release doesn't bode well in that regard. However, they have been very responsive to the larger community and these additions and changes are really a good thing. Mostly they break out rendering pipelines to support multiple renderers, and they reduce opportunities for mutations, which fly in the face of a flux-like workflow.

Touche 11y ago

> Only after a 1.0 release. 0.x implies that breaking changes are always possible Yes, which is why so many projects never reach 1.0. There are basically 2 types: 1. Those who don't want to have to care about compatibility at all. 2. Those who care about compatibility a little bit but don't want a large version number. React seems to fall into #2 here. They want a small version number and the perception of stability. But in reality there have been 14 breaking changes, this is version 14 software. It's easier to convince someone to upgrade from 0.13 to 0.14 than it is 1.0 to 2.0 even though breaking changes are just as likely in the former. But the latter has a graver perception.

danabramov 11y ago
>2. Those who care about compatibility a little bit but don't want a large version number. >React seems to fall into #2 here. Seriously, a library that goes out of its way to provide useful deprecation warnings and always keeping deprecated behavior for a version, with versions coming out once in three months, and released with codemods automating the transition for you, cares a little about compatibility? React team will eventually jump to bumping major, and it's a good question to ask, but it's a good question to ask the team instead of guessing what and why they do. https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning
- Touche 11y ago
  > cares a little about compatibility? Yes, they care. But they care more about their ability to make breaking changes without the stench of a major version bump. You have to ask, why is it currently not 1.0? The roadmap you linked doesn't mention it. There's a reason. So what is it? By the way, I know you're a huge React cheerleader and that's fine, and you think I'm being critical of React here and you need to defend this. But I'm not, this is a problem throughout the JavaScript community and really the fault lies there, not with any one particular project which is doing something a lot of others are also doing.
  - clessg 11y ago
    > But they care more about their ability to make breaking changes without the stench of a major version bump. Source?
  - Gigablah 11y ago
    > But I'm not, this is a problem throughout the JavaScript community and really the fault lies there Did you see the complaints when Node went from 0.12 to 4.0?
- Silhouette 11y ago
  Seriously, a library that goes out of its way to provide useful deprecation warnings and always keeping deprecated behavior for a version, with versions coming out once in three months, and released with codemods automating the transition for you, cares a little about compatibility? Yes, any library that breaks code written according to documented good practices less than six months earlier only cares a little about compatibility. Everything else you mentioned may be true, but it's also mostly irrelevant. This isn't necessarily a criticism of the React team. As I mentioned in another post, it's not as if they're advertising more compatibility than this and then not living up to what they claimed. The problem is some people having unrealistic expectations and reading more into the high profile of React than they should. But mere months between fundamental breaking changes in published interfaces isn't a good level of stability and longevity for most production projects, and for any of those projects that don't have realistic plans and resources available for maintaining the integration regularly, React isn't ready yet.
  - tracker1 11y ago
    Most breaking changes are including warnings 2 versions ahead of time... In TFA they outlined, iirc, 2 changes that would have less time than this. This isn't a magical, final interface we're dealing with... it's iterative changes over time. TBH, I don't like getting stuck at one point.. in practice those using React have been embracing the one-way flow that flux-like frameworks bring... This has been distilled down to Redux (imo, the best workflow option for React), which has signalled some distillation in terms of the interfaces React exposes. This is combined with different rendering paths coming to light, and I think it's pretty great. I'm currently working in an environment that is transitioning from the old-way, to a more current way of doing things. I've been working with node since pretty early on (0.4) and was following it before that. The more I've embraced this continuously updating workflow, the less friction I've experienced as a whole. That doesn't mean no pain, just less of it overall. The React/Facebook guys have been very good members in this larger community, and I applaud them for their efforts... Dropping their own render in favor of Babel, and reducing some of their mutation enablers only show them to be working with feedback from the community. It may be at a pace that's harder to keep up with, but that doesn't mean that they shouldn't be doing it.
  - 11y ago

draw_down 11y ago

> Only after a 1.0 release. 0.x implies that breaking changes are always possible Oh, I didn't know that, it's unfortunate. IMO, just bump major version every time compat breaks. Otherwise projects end up mincing around forever trying to decide when the shiny 1.0 ribbon can be affixed.

Touche 11y ago
> IMO, just bump major version every time compat breaks. Some projects do this but most do not. The reason is that if you're using a project that's on version 3 and 6 months from now it's on version 12 that's going to make you think twice about using it. No one wants to go through upgrade pains constantly. The "hack" is to never go 1.0 to hide how often you are really breaking APIs. In reality breaking APIs should be a big freaking deal. You shouldn't do it often. You shouldn't do it just because you realized some other API might be slightly nicer. Once the shine wears off people want stability.
- tracker1 11y ago
  I think pre 1.0 should represent that breaking changes are happening more often.. a 3-month release cycle with breaking changes in pretty much every stable release doesn't bode well in that regard. However, they have been very responsive to the larger community and these additions and changes are really a good thing. Mostly they break out rendering pipelines to support multiple renderers, and they reduce opportunities for mutations, which fly in the face of a flux-like workflow.