6 ms·

Node.js has been out for 4 years and it's only at 0.10.23? At this rate it will be 50 years before they get to version 1.0

by JDDunn9 13y ago

atwebb 13y ago
And then it will be at 10.0 a year later, at least that's the way these things seem to happen.
- Cthulhu_ 13y ago
  Only in browsers, and only if The Other Guy is doing it, :p.
  - oblio 13y ago
    Or if you're Slackware Linux: "In 1999, Slackware's release number jumped from 4 to 7. Patrick Volkerding explained this as a marketing effort to show that Slackware was as up-to-date as other Linux distributions, many of which had release numbers of 6 at the time, and Volkerding expected them to reach version 7 by the time of the jump." http://en.wikipedia.org/wiki/Slackware http://en.wikipedia.org/wiki/Slackware
jared314 13y ago
I believe you are using the wrong metric to measure software maturity.
- JDDunn9 13y ago
  What's the right metric? Pre 1.0 typically means the software is still in beta. I realize node.js is used by many sites and large sites, but if it is stable/reliable the versioning should reflect that.
  - kintamanimatt 13y ago
    As with people, pay attention to what it does rather than what it says. The right metric is action, not words or labels!
  - samspot 13y ago
    There is an annoying trend in software where the devs want 1.0.0 to be the final version. Look at c3p0.
- angersock 13y ago
  http://semver.org/ http://semver.org/
  - jared314 13y ago
    Can you expand on that any further? I can't tell what you are trying to say, because my comment was made in awareness of Semantic Versioning. While I support a de facto standard around the meaning of version numbers, you must judge a project's version number by the versioning rules the development team communicates. By the Semantic Versioning Specification's own guidelines, Node.js should be at least at v1.0.0, but the developers have decided against it. Therefore, when judging the stability and maturity of Node.js by the version number alone, you can only compare it to previous releases of Node.js.
  - elwell 13y ago
    In the "Semantic Versioning Specification", it's seems inconsistent when you look at #4 and #5 and compare it to rule #1 at the top. Changes in x (x.y.z) should be reserved for "when you make incompatible API changes", but the #5 in the spec forces you to change x (to 1) even in some situations where there may not be "incompatible API changes".
hacknat 13y ago
I can't tell if you're being sarcastic.
sheetjs 13y ago
Just because a build is stable (which is what 0.10.23 stable means) doesn't mean the APIs are stable (which is what 1.0.0 generally means). For example, the streams API hasn't been deemed stable. The specific build is stable, but it's possible that the interface may radically change in the near future. http://semver.org/ http://semver.org/
- leokun 13y ago
  One might just want to assume that node.js never wants to build a stable API. They are constantly breaking backwards compatibility and committing to "stable" at this point seems unrealistic. If they'd ever release a stable version they'd suddenly have to backport fixes and care about keeping an API intact for something other than a few months. Like they will not be able to do that thing anymore where they dismiss all those who built upon 0.6 and don't get security updates unless they rewrite big portions of their code base and find new libraries to replace all those they use that have gone dark. Have they at least committed to some kind of date range for a stable API? It's kind of silly to worry about because all the various node.js libraries that so many people depend upon are either weekend fads that get abandoned, or moving at the same speeds and likewise breaking compatibility.
  - sheetjs 13y ago
    > They are constantly breaking backwards compatibility and committing to "stable" at this point seems unrealistic. The team claims to have turned the corner. relevant comment from @isaacs: https://www.youtube.com/watch?v=82hJbjqbIt4#t=120 https://www.youtube.com/watch?v=82hJbjqbIt4#t=120 > Have they at least committed to some kind of date range for a stable API? @isaacs mentioned 2014 once. From the same talk, https://www.youtube.com/watch?v=82hJbjqbIt4#t=730 https://www.youtube.com/watch?v=82hJbjqbIt4#t=730
    - leokun 13y ago
      Oh that's awesome then. I hope it happens.
  - nashequilibrium 13y ago
swang 13y ago
From what I understand, 0.12 (odd numbers are used to test new features before the next even number release, and right now they are at 0.11) will be the last version before they go to 1.0
- bodyfour 13y ago
  Does anyone know approximately how close we are to 0.12? I know 0.11.9 came out a few weeks ago, but I don't follow the community close enough to get a feel for how near the next stable branch is.
  - malandrew 13y ago
    I reckon we'd move to 0.12 when there is a change that warrants a minor version bump. Whether or not there are such changes already in one of the development branches that are soon to be pulled into master, I do no know.

Node.js has been out for 4 years and it's only at 0.10.23? At this rate it will be 50 years before they get to version 1.0

by JDDunn9 13y ago

Node.js has been out for 4 years and it's only at 0.10.23? At this rate it will be 50 years before they get to version 1.0

atwebb 13y ago

And then it will be at 10.0 a year later, at least that's the way these things seem to happen.

Cthulhu_ 13y ago
Only in browsers, and only if The Other Guy is doing it, :p.
- oblio 13y ago
  Or if you're Slackware Linux: "In 1999, Slackware's release number jumped from 4 to 7. Patrick Volkerding explained this as a marketing effort to show that Slackware was as up-to-date as other Linux distributions, many of which had release numbers of 6 at the time, and Volkerding expected them to reach version 7 by the time of the jump." http://en.wikipedia.org/wiki/Slackware http://en.wikipedia.org/wiki/Slackware

jared314 13y ago

I believe you are using the wrong metric to measure software maturity.

JDDunn9 13y ago
What's the right metric? Pre 1.0 typically means the software is still in beta. I realize node.js is used by many sites and large sites, but if it is stable/reliable the versioning should reflect that.
- kintamanimatt 13y ago
  As with people, pay attention to what it does rather than what it says. The right metric is action, not words or labels!
- samspot 13y ago
  There is an annoying trend in software where the devs want 1.0.0 to be the final version. Look at c3p0.
angersock 13y ago
http://semver.org/ http://semver.org/
- jared314 13y ago
  Can you expand on that any further? I can't tell what you are trying to say, because my comment was made in awareness of Semantic Versioning. While I support a de facto standard around the meaning of version numbers, you must judge a project's version number by the versioning rules the development team communicates. By the Semantic Versioning Specification's own guidelines, Node.js should be at least at v1.0.0, but the developers have decided against it. Therefore, when judging the stability and maturity of Node.js by the version number alone, you can only compare it to previous releases of Node.js.
- elwell 13y ago
  In the "Semantic Versioning Specification", it's seems inconsistent when you look at #4 and #5 and compare it to rule #1 at the top. Changes in x (x.y.z) should be reserved for "when you make incompatible API changes", but the #5 in the spec forces you to change x (to 1) even in some situations where there may not be "incompatible API changes".

hacknat 13y ago

I can't tell if you're being sarcastic.

sheetjs 13y ago

Just because a build is stable (which is what 0.10.23 stable means) doesn't mean the APIs are stable (which is what 1.0.0 generally means). For example, the streams API hasn't been deemed stable. The specific build is stable, but it's possible that the interface may radically change in the near future. http://semver.org/ http://semver.org/

leokun 13y ago
One might just want to assume that node.js never wants to build a stable API. They are constantly breaking backwards compatibility and committing to "stable" at this point seems unrealistic. If they'd ever release a stable version they'd suddenly have to backport fixes and care about keeping an API intact for something other than a few months. Like they will not be able to do that thing anymore where they dismiss all those who built upon 0.6 and don't get security updates unless they rewrite big portions of their code base and find new libraries to replace all those they use that have gone dark. Have they at least committed to some kind of date range for a stable API? It's kind of silly to worry about because all the various node.js libraries that so many people depend upon are either weekend fads that get abandoned, or moving at the same speeds and likewise breaking compatibility.
- sheetjs 13y ago
  > They are constantly breaking backwards compatibility and committing to "stable" at this point seems unrealistic. The team claims to have turned the corner. relevant comment from @isaacs: https://www.youtube.com/watch?v=82hJbjqbIt4#t=120 https://www.youtube.com/watch?v=82hJbjqbIt4#t=120 > Have they at least committed to some kind of date range for a stable API? @isaacs mentioned 2014 once. From the same talk, https://www.youtube.com/watch?v=82hJbjqbIt4#t=730 https://www.youtube.com/watch?v=82hJbjqbIt4#t=730
  - leokun 13y ago
    Oh that's awesome then. I hope it happens.
- nashequilibrium 13y ago

swang 13y ago

From what I understand, 0.12 (odd numbers are used to test new features before the next even number release, and right now they are at 0.11) will be the last version before they go to 1.0

bodyfour 13y ago
Does anyone know approximately how close we are to 0.12? I know 0.11.9 came out a few weeks ago, but I don't follow the community close enough to get a feel for how near the next stable branch is.
- malandrew 13y ago
  I reckon we'd move to 0.12 when there is a change that warrants a minor version bump. Whether or not there are such changes already in one of the development branches that are soon to be pulled into master, I do no know.