5 ms·

I realize this follows semver, but bumping major releases without major changes is... not as fun? as the 'old days' where major versions of software meant somet

by gedy 10y ago

I realize this follows semver, but bumping major releases without major changes is... not as fun? as the 'old days' where major versions of software meant something less incremental :-) Kind of wish there was yet another number prefix to semver to signify this.

jasnell 10y ago
There are a number of semver-major changes included in v7. That said, the goal for this release has been improved stability and performance over new features so the jump from v6 to v7 is fairly small.
- andrewstuart2 10y ago
  I think gedy meant that it used to be that "v7.0 released!" meant that one could expect exciting, fun features to be present, and that the new version is worth taking a look at, and playing with. With semver, it seems like a lot of "new features" are typically released in minor versions, since quite often they don't need to break compatibility in order to introduce features. So major versions are, to me, almost more of a cause for concern these days. My first thought is typically "Oh no, what part of my stack is going to break now? How much time will I spend tracking down the fix?"
  - nothrabannosir 10y ago
    So major versions are, to me, almost more of a cause for concern these days. My first thought is typically "Oh no, what part of my stack is going to break now? How much time will I spend tracking down the fix?" Isn't that exactly the point of semver? And, assuming things will break at some point,* isn't that great? Now you know when to expect it. Semver doesn't influence design decisions of a project's lifetime. It describes them. * fair assumption, unless you're dealing with software which literally never breaks backwards compatibility.
    - andrewstuart2 10y ago
      Yeah, that's definitely the point of SemVer. The only point I'm (and presumably gedy is) making is that a major version no longer feels like Christmas morning, but rather akin to "see me in my office tomorrow morning." Okay, not quite that bad, but in the same vein. SemVer is great and helpful and I wouldn't choose anything else currently, but it also lacks the builtin PR that old-school major versions seemed to have, where major version bumps usually meant you could get excited about exploring new major features. There's nothing special about a minor SemVer bump that says "new major features have been introduced." The spec only asserts that minor means new features. That is, there's no obvious way to know that 1.1 introduced only one new method for checking status, while 1.2 introduced a new magic() method that finishes your work for you and makes all your dreams come true. :-P
      - nothrabannosir 10y ago
        Great point. In retrospect, that should have been clear to me from your comment. Sorry for ruining the thread :/
        andrewstuart2 10y ago
        Eh, no harm no foul. :-) I could have been more clear, if there was still room for misunderstanding, and it gave me the chance to mentally flesh out my thoughts a bit better as well. :-)
sosuke 10y ago
I would propose the bang but they are thrown around too much to have any impact. Node.js V7 Node.js V8! (denotes something significant)
STRiDEX 10y ago
Node v7 has async await behind a harmony flag!
- koolba 10y ago
  I'd call that a big feature.
  - weego 10y ago
    The entire point of it being behind a flag is that it's not considered stable, so is not a feature.
    - joshmanders 10y ago
      It's only unstable because the version of V8 is marked as unstable. Newer versions of V8 have async/await as stable. TSC member jasnell has stated if things go smoothly, we can see async/await stable in a minor version release of v7.
      - sscotth 10y ago
        Correct. async/await was first introduced V8 v5.2 but put behind an testing flag. Node.js v7 includes the latest stable version of V8 (v5.4) which was promoted two weeks ago but still has it behind a flag. The current beta version of V8 (v5.5) now has async/await enabled by default. Shortly after V8 v5.5 goes stable, in about 4 weeks, Node.js will update to include it. However, it will most likely be only updated on the v7 branch and not the v6 LTS branch. Also of note, chakra still has async/await behind a flag as well.
leeoniya 10y ago
there are a lot of deprecated things removed, look at all the issues marked [SEMVER-MAJOR]
Klathmon 10y ago
IMO until someone can figure out a way to objectively "quantify" the size of a change, it should stay with how semver has it. The line of "major" is arbitrary, and changes per person. It's basically useless information to everyone but the person/people actually making the version change. Having it there can just lead to anger when something that you would consider "major" doesn't make the cut, or when the "major" bump doesn't have anything you care about. Semver is in no way the end-all-be-all of versioning schemes, but at least it's pretty objective for the most part in the sense that it can prevent bikeshedding about version numbers, while still giving some useful information to the users. That being said, I'd love a system that lets me view changelogs by the version "level" I want. So I can easily lookup the major changes since v6.6, and someone else can check what has change since v4.2, etc... With Semver a lot of my time is spent reviewing every changelog between my current version and the one i'm bumping to, and there's no reason it needs to be that way.
- gregmac 10y ago
  It's even more nuanced than that. If I release 1.0, then add a couple "medium" size features and release as 1.1 a month or so later, I can keep doing this indefinitely with 1.2, 1.3, etc. Baring some truly some new big thing or a fundamental change in functionality, it becomes very unclear as to when to release "2.0" or what even makes it different than the other 1.x releases. On the other hand, if I do the exact same work of adding a couple features per month, but don't actually release, I could then make a big splash a year later with 2.0 that had 19 new features, and I think most people could readily agree that qualifies as a "major" release. From a quality point of view, release early, release often is very useful: get feedback quickly, iterate in small chunks, minimize breakage. However, from a marketing point of view, this is boring -- especially by the time you're on 1.19 and your features are largely quality-of-life or only affect a small segment of the market. A big 2.0 release that gets press releases and such is much more exciting.
  - Klathmon 10y ago
    You bring up a good point about marketing. Maybe version "names" could be helpful here. Make a marketing "name" and use that as a way of showing off what's new, while still keeping semver true to it's name. In your example, version 1.3 could be "Saucy Gorilla", while 1.8 could be "Delicate Apricot", and when you feel it's change enough from the start, you can pick an arbitrary point and make a new name and blog post. It would still have some of the bikeshedding that older "major.minor" version schemes have, but it could be not as bad because it is more obviously arbitrary.
MikeKusold 10y ago
When I'm writing Javascript, I don't want to have to think about which version of NodeJS it is running on. I appreciate that major releases are boring to everyone except for people using C bindings.
Hurtak 10y ago
I have read this comment which suggests async/await in Node 7 (V8 5.4) is buggy. Anybody has some more information about that? > I'm glad to hear so much excitement about async/await. However, Node v7 is based on V8 54, whose async/await implementation has some bugs in it (including a nasty memory leak). I would not recommend using --harmony-async-await in production until upgrading to V8 55 source: https://github.com/nodejs/promises/issues/4#issuecomment-254159118 https://github.com/nodejs/promises/issues/4#issuecomment-254...
mburst 10y ago
There are several breaking changes which makes it a good use case for the major version upgrade. Also the odd major numbers for node aren't LTS versions so I imagine they'll be adding a ton more features before releasing v8 LTS.
jbergstroem 10y ago
I think this is the dilemma of semver versus "market" versioning. If true semver is confusing, perhaps stick with the LTS releases which are named differently (one of the reasons being clear communication)? The LTS versions are named after the periodic table of elements, starting at a and moving forward. First one was "Argon" (4.x), second "Boron" (6.x). You can read more on LTS and naming here: https://github.com/nodejs/LTS https://github.com/nodejs/LTS
TheRealPomax 10y ago
Yeah but as backward compatibility breaking change, where would that number go? Presumably still at the front, because it's the most important number for version checking, and then it'll still feel like the number that reflects a "big change" =)

by gedy 10y ago

jasnell 10y ago

There are a number of semver-major changes included in v7. That said, the goal for this release has been improved stability and performance over new features so the jump from v6 to v7 is fairly small.

andrewstuart2 10y ago
I think gedy meant that it used to be that "v7.0 released!" meant that one could expect exciting, fun features to be present, and that the new version is worth taking a look at, and playing with. With semver, it seems like a lot of "new features" are typically released in minor versions, since quite often they don't need to break compatibility in order to introduce features. So major versions are, to me, almost more of a cause for concern these days. My first thought is typically "Oh no, what part of my stack is going to break now? How much time will I spend tracking down the fix?"
- nothrabannosir 10y ago
  So major versions are, to me, almost more of a cause for concern these days. My first thought is typically "Oh no, what part of my stack is going to break now? How much time will I spend tracking down the fix?" Isn't that exactly the point of semver? And, assuming things will break at some point,* isn't that great? Now you know when to expect it. Semver doesn't influence design decisions of a project's lifetime. It describes them. * fair assumption, unless you're dealing with software which literally never breaks backwards compatibility.
  - andrewstuart2 10y ago
    Yeah, that's definitely the point of SemVer. The only point I'm (and presumably gedy is) making is that a major version no longer feels like Christmas morning, but rather akin to "see me in my office tomorrow morning." Okay, not quite that bad, but in the same vein. SemVer is great and helpful and I wouldn't choose anything else currently, but it also lacks the builtin PR that old-school major versions seemed to have, where major version bumps usually meant you could get excited about exploring new major features. There's nothing special about a minor SemVer bump that says "new major features have been introduced." The spec only asserts that minor means new features. That is, there's no obvious way to know that 1.1 introduced only one new method for checking status, while 1.2 introduced a new magic() method that finishes your work for you and makes all your dreams come true. :-P
    - nothrabannosir 10y ago
      Great point. In retrospect, that should have been clear to me from your comment. Sorry for ruining the thread :/
      - andrewstuart2 10y ago
        Eh, no harm no foul. :-) I could have been more clear, if there was still room for misunderstanding, and it gave me the chance to mentally flesh out my thoughts a bit better as well. :-)

sosuke 10y ago

I would propose the bang but they are thrown around too much to have any impact. Node.js V7 Node.js V8! (denotes something significant)

STRiDEX 10y ago

Node v7 has async await behind a harmony flag!

koolba 10y ago
I'd call that a big feature.
- weego 10y ago
  The entire point of it being behind a flag is that it's not considered stable, so is not a feature.
  - joshmanders 10y ago
    It's only unstable because the version of V8 is marked as unstable. Newer versions of V8 have async/await as stable. TSC member jasnell has stated if things go smoothly, we can see async/await stable in a minor version release of v7.
    - sscotth 10y ago
      Correct. async/await was first introduced V8 v5.2 but put behind an testing flag. Node.js v7 includes the latest stable version of V8 (v5.4) which was promoted two weeks ago but still has it behind a flag. The current beta version of V8 (v5.5) now has async/await enabled by default. Shortly after V8 v5.5 goes stable, in about 4 weeks, Node.js will update to include it. However, it will most likely be only updated on the v7 branch and not the v6 LTS branch. Also of note, chakra still has async/await behind a flag as well.

leeoniya 10y ago

there are a lot of deprecated things removed, look at all the issues marked [SEMVER-MAJOR]

Klathmon 10y ago

IMO until someone can figure out a way to objectively "quantify" the size of a change, it should stay with how semver has it. The line of "major" is arbitrary, and changes per person. It's basically useless information to everyone but the person/people actually making the version change. Having it there can just lead to anger when something that you would consider "major" doesn't make the cut, or when the "major" bump doesn't have anything you care about. Semver is in no way the end-all-be-all of versioning schemes, but at least it's pretty objective for the most part in the sense that it can prevent bikeshedding about version numbers, while still giving some useful information to the users. That being said, I'd love a system that lets me view changelogs by the version "level" I want. So I can easily lookup the major changes since v6.6, and someone else can check what has change since v4.2, etc... With Semver a lot of my time is spent reviewing every changelog between my current version and the one i'm bumping to, and there's no reason it needs to be that way.

gregmac 10y ago
It's even more nuanced than that. If I release 1.0, then add a couple "medium" size features and release as 1.1 a month or so later, I can keep doing this indefinitely with 1.2, 1.3, etc. Baring some truly some new big thing or a fundamental change in functionality, it becomes very unclear as to when to release "2.0" or what even makes it different than the other 1.x releases. On the other hand, if I do the exact same work of adding a couple features per month, but don't actually release, I could then make a big splash a year later with 2.0 that had 19 new features, and I think most people could readily agree that qualifies as a "major" release. From a quality point of view, release early, release often is very useful: get feedback quickly, iterate in small chunks, minimize breakage. However, from a marketing point of view, this is boring -- especially by the time you're on 1.19 and your features are largely quality-of-life or only affect a small segment of the market. A big 2.0 release that gets press releases and such is much more exciting.
- Klathmon 10y ago
  You bring up a good point about marketing. Maybe version "names" could be helpful here. Make a marketing "name" and use that as a way of showing off what's new, while still keeping semver true to it's name. In your example, version 1.3 could be "Saucy Gorilla", while 1.8 could be "Delicate Apricot", and when you feel it's change enough from the start, you can pick an arbitrary point and make a new name and blog post. It would still have some of the bikeshedding that older "major.minor" version schemes have, but it could be not as bad because it is more obviously arbitrary.

MikeKusold 10y ago

When I'm writing Javascript, I don't want to have to think about which version of NodeJS it is running on. I appreciate that major releases are boring to everyone except for people using C bindings.

Hurtak 10y ago

I have read this comment which suggests async/await in Node 7 (V8 5.4) is buggy. Anybody has some more information about that? > I'm glad to hear so much excitement about async/await. However, Node v7 is based on V8 54, whose async/await implementation has some bugs in it (including a nasty memory leak). I would not recommend using --harmony-async-await in production until upgrading to V8 55 source: https://github.com/nodejs/promises/issues/4#issuecomment-254159118 https://github.com/nodejs/promises/issues/4#issuecomment-254...

mburst 10y ago

There are several breaking changes which makes it a good use case for the major version upgrade. Also the odd major numbers for node aren't LTS versions so I imagine they'll be adding a ton more features before releasing v8 LTS.

jbergstroem 10y ago

I think this is the dilemma of semver versus "market" versioning. If true semver is confusing, perhaps stick with the LTS releases which are named differently (one of the reasons being clear communication)? The LTS versions are named after the periodic table of elements, starting at a and moving forward. First one was "Argon" (4.x), second "Boron" (6.x). You can read more on LTS and naming here: https://github.com/nodejs/LTS https://github.com/nodejs/LTS

TheRealPomax 10y ago

Yeah but as backward compatibility breaking change, where would that number go? Presumably still at the front, because it's the most important number for version checking, and then it'll still feel like the number that reflects a "big change" =)