3 ms·

No api stability promises before 1.0 is technically part of semver. It sounds like io.js should have stayed below 1.0 if they broke backwards compatibility thre

by ploxiln 11y ago

No api stability promises before 1.0 is technically part of semver. It sounds like io.js should have stayed below 1.0 if they broke backwards compatibility three times in less than a year! I always found the naming-and-proclaiming of semver in the javascript community silly. Old style C libs have been doing what semver describes for decades, and while the js community talks it up like crazy, the compatibility and stability is terrible (and as a result they find the need for private recursive sub-dependencies, and the resulting thousands of unique libs/copies is impossible to audit or patch).

bsimpson 11y ago
The Node library is massive, and tightly coupled to V8. The changes that bumped the major version weren't major changes for most people, just for those who happened to be using the parts of the library that changed. Maybe that's a deficiency in semver (or the way io.js used it), but going to v4 in one year isn't as unstable as it sounds; it's just following Chrome's example of not caring how big the version number gets, so long as the semantics make sense. I believe the io.js community was in the "ship or get off the pot" camp, and found it silly that Node was a critical piece of infrastructure at firms like PayPal while still technically not having had a GM release. By forcing the issue, they got Joyent to commit to major version changes twice a year, which sounds like a reasonable compromise between everything-changing-all-the-time and we-can't-have-new-things-because-legacy.
- ploxiln 11y ago
  python also has a pretty big standard library. I don't have much specific experience before python 2.5, but I do know that code written for python 2.5 (released in 2006) is just about 100% compatible with python 2.7 which still has support and patch releases. Backwards compatibility was broken once in the last decade, for 3.x. Or consider gtk+. 2.x was backwards ABI (binary!) compatible for over a decade. Compatibility was broken once in the last decade, for 3.x (for applications. for themes and windowing environments is a different story unfortunately.) So programs written for 2.10 or so still work today with (still continuing) recent releases of 2.x.
- lobster_johnson 11y ago
  It's a good argument for adding another level in addition to semver: A human-oriented release number. After all, when a project goes from 2.0 to 3.0, you expect something big to have happened -- not just some breakage. Some projects use release names (e.g., Ubuntu and Android), but if every project starts using release names we'll have a lot of (mostly silly) names to deal with on a daily basis. Plus, there's no inherent ordering in names.
- xg15 11y ago
  > ... but going to v4 in one year isn't as unstable as it sounds; it's just following Chrome's example of not caring how big the version number gets, so long as the semantics make sense. Except that Chrome is mainly an application for end users and not a library, so the implications of "breaking changes" are a lot less severe anyway. In the parts where it does provide APIs (e.g. to websites or add-ons), the compatibility policies are a lot stricter than semver would require.

by ploxiln 11y ago

bsimpson 11y ago

The Node library is massive, and tightly coupled to V8. The changes that bumped the major version weren't major changes for most people, just for those who happened to be using the parts of the library that changed. Maybe that's a deficiency in semver (or the way io.js used it), but going to v4 in one year isn't as unstable as it sounds; it's just following Chrome's example of not caring how big the version number gets, so long as the semantics make sense. I believe the io.js community was in the "ship or get off the pot" camp, and found it silly that Node was a critical piece of infrastructure at firms like PayPal while still technically not having had a GM release. By forcing the issue, they got Joyent to commit to major version changes twice a year, which sounds like a reasonable compromise between everything-changing-all-the-time and we-can't-have-new-things-because-legacy.

ploxiln 11y ago
python also has a pretty big standard library. I don't have much specific experience before python 2.5, but I do know that code written for python 2.5 (released in 2006) is just about 100% compatible with python 2.7 which still has support and patch releases. Backwards compatibility was broken once in the last decade, for 3.x. Or consider gtk+. 2.x was backwards ABI (binary!) compatible for over a decade. Compatibility was broken once in the last decade, for 3.x (for applications. for themes and windowing environments is a different story unfortunately.) So programs written for 2.10 or so still work today with (still continuing) recent releases of 2.x.
lobster_johnson 11y ago
It's a good argument for adding another level in addition to semver: A human-oriented release number. After all, when a project goes from 2.0 to 3.0, you expect something big to have happened -- not just some breakage. Some projects use release names (e.g., Ubuntu and Android), but if every project starts using release names we'll have a lot of (mostly silly) names to deal with on a daily basis. Plus, there's no inherent ordering in names.
xg15 11y ago
> ... but going to v4 in one year isn't as unstable as it sounds; it's just following Chrome's example of not caring how big the version number gets, so long as the semantics make sense. Except that Chrome is mainly an application for end users and not a library, so the implications of "breaking changes" are a lot less severe anyway. In the parts where it does provide APIs (e.g. to websites or add-ons), the compatibility policies are a lot stricter than semver would require.