> 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.
>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.
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.
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.
I think you're misunderstanding React's API surface.
It's about 20 core methods, not a giant lib like jQuery.
From my experience, a medium sized project is adjusted to the changes in about two hours. Once every three months.
It is a big deal any time someone's code works, and then they update a dependency, and then their code doesn't work any more.
Even if the actual code changes required to update the integration are minimal, someone still needs to divert to make those changes and then test everything, which is disruptive at best. Before they can do that, they need to identify what changes are required and perhaps learn how to use any automated updating tools that are available, both of which also take time. If one person on the team wants to upgrade to access some new feature or just get a bug fix, everyone else on the team has to come along, so for example they might start seeing warnings that they'll need to investigate. As I mentioned in another post, there is a nasty hidden cost to breaking the interface of fast-moving but lightly documented libraries, because it will tend to invalidate all the tutorials and example repos and demo videos and so on offered by other contributors or, worse, those resources may become actively misleading.
This is a lesson the web development community will learn in time. Unfortunately today it is a very young part of the industry, obsessed with the appearance of making progress, even though actually web development is almost comically inefficient. The lack of respect for issues like standardisation, compatibility and portability is a major contributing factor in that inefficiency, as is the willingness to build on fragile dependencies in the first place.
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.
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.