3 ms·
As another commenter answered 3 and 2 (and I agree with them), i'll answer 1: There's a difference between "has some breaking changes" and "will have basically
by Klathmon 8y ago
As another commenter answered 3 and 2 (and I agree with them), i'll answer 1:
There's a difference between "has some breaking changes" and "will have basically an entirely new API, and will support different features and make different tradeoffs"
Like for instance AngularJs 1.x vs Angular 2+, or what seems like every major version of react-router, or various other examples of this that come back around and bite people. The only difference with those is that they don't have literally 10 years of documentation, blogs, SO answers, and more with no version numbers on them.
This isn't an instance where dogmatic application of the "rules" is a good idea. This is one where choosing to make a new library under a new name is the lesser of 2 evils. The hope is it will cause less problems, less confusion, less difficulty for both new and old devs, and be better for everyone.
I don't know about you, but i've absolutely spent ~30 minutes on multiple occasions trying to figure out why some documentation seems to be wrong, or a feature isn't working in a library only to realize that i'm not on the latest version or the docs don't have an easy way to go back through old versions, and it's a big timewaste as well as a source of bugs. This move is trying to prevent that!
- Izkata 8y ago> There's a difference between "has some breaking changes" and "will have basically an entirely new API, and will support different features and make different tradeoffs" Doesn't this library also predate the semver spec, and wasn't just such major alterations the purpose of the major version number back then?