4 ms·

What is the reasoning behind the version jumps? 1.0.3->1.0.4->1.2.0->1.3.0 Sure, it's just a number, but the changelog isn't that big. Version inflation for n

What is the reasoning behind the version jumps? 1.0.3->1.0.4->1.2.0->1.3.0 Sure, it's just a number, but the changelog isn't that big. Version inflation for no particular reason, apart from marketing, seems a bit silly. What am I missing?

phpnode 12y ago
http://semver.org/ http://semver.org/
- 3princip 12y ago
  I've probably been conditioned by nodejs versioning . I guess this makes sense. Still feels strange.
  - phpnode 12y ago
    yeah, node doesn't do this. node 0.12.0 should actually be (at least) node 5.0, if they followed semver.
    - riffraff 12y ago
      I think religious following of semver doesn't matter, but semver says that pre 1.0 numbers are essentially meaningless so nodejs might be actually following it correctly. > Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
      - phpnode 12y ago
        I think not: > if your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.
        eCa 12y ago
        So, either they are using 0.y.z to allow themselves breaking changes whenever, or they are using it as a signal that it's not production-ready, or they are not following semantic versioning. Is there another alternative?
  - scrapcode 12y ago
    This prompted me to look up Node's versioning style to see if it had a name, but I couldn't find one. What I did learn is how in Node.js even numbered releases are stable and odd numbered releases are unstable. That seems pretty odd to me (no pun intended), is this normal?
    - phpnode 12y ago
      It's copied from the linux kernel - http://www.linfo.org/kernel_version_numbering.html http://www.linfo.org/kernel_version_numbering.html
      - inyourtenement 12y ago
        We should clarify that Linux no longer uses that version numbering system.
    - cursork 12y ago
      Also Perl: 5.20 is current stable, 5.21 is unstable but will eventually lead to 5.22. http://perldoc.perl.org/perlfaq1.html#How-often-are-new-versions-of-Perl-released%3f http://perldoc.perl.org/perlfaq1.html#How-often-are-new-vers...
mcosta 12y ago
semantic versioning?
- moondowner 12y ago
  A versioning convention widely used in the software industry. http://semver.org/ http://semver.org/
pilif 12y ago
They are following semver which mandates that the MINOR should be incremented if the release contains functional changes. The only reason for incrementing PATCH is if the release only contains bugfixes.
jeswin 12y ago
This is a case of the Semantic Versioning doing the job it was designed for. The 1.3.0 release just broke some poor regex I had written, since url.resolve now returns a trailing slash. Since it's a commonly used function, I have a feeling it might break a few apps out there. You shouldn't be making that kind of change in a PATCH number update. Hence the MINOR number update, perhaps. EDIT: url.resolve not path.resolve.
- chrisseaton 12y ago
  If it's a change that breaks code using the API, shouldn't it be a major version - 2.0? If you update the minor version all your changes should be backwards compatible. If you can't run an existing program, that's not backwards compatible.
  - jeswin 12y ago
    Discussion on the same point: https://github.com/iojs/io.js/pull/278 https://github.com/iojs/io.js/pull/278 From the discussion: "semver-major" label was removed because it is a bug fix: Node 0.10 has the new behavior, and also WHATWG compliance.
- deleted 12y ago
  [deleted]
  - kcbanner 12y ago
    Nothing the commenter said would indicate that tests are missing in either his code or io.js' code.
- geofft 12y ago
  That's semver doing the job people wish it were designed for, not semver doing the job it was designed for. If it broke actual user code, then it MUST be a major version bump: "Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version." The idea with semver is that you can ask for 1.2.0 or any greater 1.x.y, and your app will still work. This was broken. Maybe there's an argument that the break didn't matter that much, but it's still a spec violation. Which is why you get a bunch of annoyed people who care deeply about ABI compatibility, when asked to switch to semver, saying, "Do you really want me to release version 172.0.0?" If the rule is, bump major versions when the project maintainers think it matters, bump minor versions when they think it matters less, bump patch versions when they're pretty sure it doesn't matter, that's exactly what gets derided as "Sentimental Versioning" (http://sentimentalversioning.org/ http://sentimentalversioning.org/), just dressed up as semver, which is more harmful. If you've got to pay attention to every release's changelog and run regression tests anyway, just in case the package maintainers disagree about what's important enough for a major version bump, then you have version lock problems anyway. If semver is just guidelines and not a spec, then it should make that clear.
cwmma 12y ago
in 1.1.0 they added a couple new features such as privateEncrypt/publicDecrypt functions and publicEncrypt being able to accept a password protected private key (because you can derive a public key from a private key). These where new features so version bump. 1.2.0 added simplified stream construction so instead of being forced to subclass the built ins you could pass transform/flush/read/write/writev options to the constructor, again added feature so minor version. 1.3.0 changed the ordering of the default cipher suites so that more browsers would have perfect forward security by default. While not technically an api addition it's still more then a bug fix as it changes intended behavior so minor version. All of the releases also a ton of bug fixes.
jessaustin 12y ago
1.0.3->1.0.4->1.2.0->1.3.0 1.1 wasn't skipped: $ nvm ls-remote | grep iojs-v1.1 iojs-v1.1.0
- 3princip 12y ago
  I was mistaken that it was skipped. I haven't updated since 1.0.4 and missed it in the changelog (it is there). In hindsight the version makes sense, but I was genuinely surprised by the version number and oblivious to semver, obviously. It feels like a big departure from the old node system. Not to say that's a bad thing. The psychological effect of so many perceived changes on a platform may make it seem more unstable than it is. Having said that, io.js progress is great news for everyone in the JS/node/io community.

phpnode 12y ago

http://semver.org/ http://semver.org/

3princip 12y ago
I've probably been conditioned by nodejs versioning . I guess this makes sense. Still feels strange.
- phpnode 12y ago
  yeah, node doesn't do this. node 0.12.0 should actually be (at least) node 5.0, if they followed semver.
  - riffraff 12y ago
    I think religious following of semver doesn't matter, but semver says that pre 1.0 numbers are essentially meaningless so nodejs might be actually following it correctly. > Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
    - phpnode 12y ago
      I think not: > if your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.
      - eCa 12y ago
        So, either they are using 0.y.z to allow themselves breaking changes whenever, or they are using it as a signal that it's not production-ready, or they are not following semantic versioning. Is there another alternative?
- scrapcode 12y ago
  This prompted me to look up Node's versioning style to see if it had a name, but I couldn't find one. What I did learn is how in Node.js even numbered releases are stable and odd numbered releases are unstable. That seems pretty odd to me (no pun intended), is this normal?
  - phpnode 12y ago
    It's copied from the linux kernel - http://www.linfo.org/kernel_version_numbering.html http://www.linfo.org/kernel_version_numbering.html
    - inyourtenement 12y ago
      We should clarify that Linux no longer uses that version numbering system.
  - cursork 12y ago
    Also Perl: 5.20 is current stable, 5.21 is unstable but will eventually lead to 5.22. http://perldoc.perl.org/perlfaq1.html#How-often-are-new-versions-of-Perl-released%3f http://perldoc.perl.org/perlfaq1.html#How-often-are-new-vers...

mcosta 12y ago

semantic versioning?

moondowner 12y ago
A versioning convention widely used in the software industry. http://semver.org/ http://semver.org/

pilif 12y ago

They are following semver which mandates that the MINOR should be incremented if the release contains functional changes. The only reason for incrementing PATCH is if the release only contains bugfixes.

jeswin 12y ago

This is a case of the Semantic Versioning doing the job it was designed for. The 1.3.0 release just broke some poor regex I had written, since url.resolve now returns a trailing slash. Since it's a commonly used function, I have a feeling it might break a few apps out there. You shouldn't be making that kind of change in a PATCH number update. Hence the MINOR number update, perhaps. EDIT: url.resolve not path.resolve.

chrisseaton 12y ago
If it's a change that breaks code using the API, shouldn't it be a major version - 2.0? If you update the minor version all your changes should be backwards compatible. If you can't run an existing program, that's not backwards compatible.
- jeswin 12y ago
  Discussion on the same point: https://github.com/iojs/io.js/pull/278 https://github.com/iojs/io.js/pull/278 From the discussion: "semver-major" label was removed because it is a bug fix: Node 0.10 has the new behavior, and also WHATWG compliance.
deleted 12y ago
[deleted]
- kcbanner 12y ago
  Nothing the commenter said would indicate that tests are missing in either his code or io.js' code.
geofft 12y ago
That's semver doing the job people wish it were designed for, not semver doing the job it was designed for. If it broke actual user code, then it MUST be a major version bump: "Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version." The idea with semver is that you can ask for 1.2.0 or any greater 1.x.y, and your app will still work. This was broken. Maybe there's an argument that the break didn't matter that much, but it's still a spec violation. Which is why you get a bunch of annoyed people who care deeply about ABI compatibility, when asked to switch to semver, saying, "Do you really want me to release version 172.0.0?" If the rule is, bump major versions when the project maintainers think it matters, bump minor versions when they think it matters less, bump patch versions when they're pretty sure it doesn't matter, that's exactly what gets derided as "Sentimental Versioning" (http://sentimentalversioning.org/ http://sentimentalversioning.org/), just dressed up as semver, which is more harmful. If you've got to pay attention to every release's changelog and run regression tests anyway, just in case the package maintainers disagree about what's important enough for a major version bump, then you have version lock problems anyway. If semver is just guidelines and not a spec, then it should make that clear.

cwmma 12y ago

in 1.1.0 they added a couple new features such as privateEncrypt/publicDecrypt functions and publicEncrypt being able to accept a password protected private key (because you can derive a public key from a private key). These where new features so version bump. 1.2.0 added simplified stream construction so instead of being forced to subclass the built ins you could pass transform/flush/read/write/writev options to the constructor, again added feature so minor version. 1.3.0 changed the ordering of the default cipher suites so that more browsers would have perfect forward security by default. While not technically an api addition it's still more then a bug fix as it changes intended behavior so minor version. All of the releases also a ton of bug fixes.

jessaustin 12y ago

1.0.3->1.0.4->1.2.0->1.3.0 1.1 wasn't skipped: $ nvm ls-remote | grep iojs-v1.1 iojs-v1.1.0

3princip 12y ago
I was mistaken that it was skipped. I haven't updated since 1.0.4 and missed it in the changelog (it is there). In hindsight the version makes sense, but I was genuinely surprised by the version number and oblivious to semver, obviously. It feels like a big departure from the old node system. Not to say that's a bad thing. The psychological effect of so many perceived changes on a platform may make it seem more unstable than it is. Having said that, io.js progress is great news for everyone in the JS/node/io community.