5 ms·

What happened with the version numbers? I could have sworn Node was on v0.10 just a couple of months back?

M2Ys4U 11y ago
Joyent were incompetent stewards of the node project, so it was forked into "iojs". The iojs project adopted the semantic versioning system, where a new major version number indicates backwards-compatible changes (which mainly happen when they update the version of V8). Eventually Joyent recognised they were on the losing side, and so they agreed to merge back together, under a new foundation which was set up with the help of the Linux Foundation. Node.js v4 is the first release from the newly merged projects and they used v4 as iojs had already made it to v3.
- lucio 11y ago
  *incompatible
  - dickeytk 11y ago
    that's not what he meant
    - DCoder 11y ago
      > where a new major version number indicates backwards-compatible changes lucio was probably referring to this part, where "incompatible" is indeed correct.
      - progx 11y ago
        lol
  - M2Ys4U 11y ago
    Whoops! That's a bit of a glaring error, sorry about that.
  - deleted 11y ago
    [deleted]
bsimpson 11y ago
A group of contributors got tired of Node not using semver when the rest of the ecosystem does (among other gripes). They forked it and shipped io.js v1.0.0. In keeping with semver, they bumped the major version number on every breaking change. According to iojs.org, the most recent version is v3.3.0. Joyent and the io.js team reconciled and merged their codebases, maintaining everyone's versions. Since io.js had used versions 1 - 3, the merged version number is 4.
- 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.
ihsw 11y ago
NodeJS was forked into io.js, which continued ahead onto 2.0 and 3.0. Now the two projects are merging back and they are continuing with io.js version numbering rather than Node's, starting with version 4.0 today.
0xCMP 11y ago
So many versions of this story as all the other comments under this one show.

Joyent were incompetent stewards of the node project, so it was forked into "iojs". The iojs project adopted the semantic versioning system, where a new major version number indicates backwards-compatible changes (which mainly happen when they update the version of V8). Eventually Joyent recognised they were on the losing side, and so they agreed to merge back together, under a new foundation which was set up with the help of the Linux Foundation. Node.js v4 is the first release from the newly merged projects and they used v4 as iojs had already made it to v3.

lucio 11y ago
*incompatible
- dickeytk 11y ago
  that's not what he meant
  - DCoder 11y ago
    > where a new major version number indicates backwards-compatible changes lucio was probably referring to this part, where "incompatible" is indeed correct.
    - progx 11y ago
      lol
- M2Ys4U 11y ago
  Whoops! That's a bit of a glaring error, sorry about that.
- deleted 11y ago
  [deleted]

bsimpson 11y ago

A group of contributors got tired of Node not using semver when the rest of the ecosystem does (among other gripes). They forked it and shipped io.js v1.0.0. In keeping with semver, they bumped the major version number on every breaking change. According to iojs.org, the most recent version is v3.3.0. Joyent and the io.js team reconciled and merged their codebases, maintaining everyone's versions. Since io.js had used versions 1 - 3, the merged version number is 4.

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.

ihsw 11y ago

NodeJS was forked into io.js, which continued ahead onto 2.0 and 3.0. Now the two projects are merging back and they are continuing with io.js version numbering rather than Node's, starting with version 4.0 today.

0xCMP 11y ago

So many versions of this story as all the other comments under this one show.