4 ms·

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,

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.
  - WorldMaker 10y ago
    I tried to make this very argument with a former employer. Who cares about numbers except for weird technical people? Just pick a cool marketing name and market the heck out of that that. "But we've always marketed 2.0 or 3.0..." So what? I suppose there's a small psychological benefit in a monotonically increasing number, but it doesn't really tell you anything more than "Saucy Gorilla" in terms of what is in a release. It can help you order the releases if you need to know which release came first, but you can alphabetize your codenames or even just have a lookup table for those rare times that actually matters.
    - isaacaggrey 10y ago
      Ubuntu is an example of doing both an increasing number (by year.month) and marketing name. Recently: 16.10 (Yakkety Yak), 16.04 (Xenial Xerus), etc. However, it seems Canonical keeps the codename out of their official press release: https://insights.ubuntu.com/2016/10/13/canonical-releases-ubuntu-16-10/ https://insights.ubuntu.com/2016/10/13/canonical-releases-ub...
- Jarwain 10y ago
  I've always thought of a major release as being one that isn't backwards compatible/include breaking changes
  - Ajedi32 10y ago
    Yes, that's exactly what it means for any project using [SemVer](http://semver.org/ http://semver.org/). It says nothing about how many new features you added or anything like that, only that you introduced breaking changes.
- franciscop 10y ago
  What I do is keep bundling things together in a dev branch for a while and wait until I have to introduce a breaking change to release it all as a major version. Of course only with smaller projects where a new feature might be 3-4h of work, I cannot think Node.js waiting to introduce new features just for doing a marketing stunt. Example: https://github.com/umbrellajs/umbrella/milestone/8?closed=1 https://github.com/umbrellajs/umbrella/milestone/8?closed=1
oso2k 10y ago
It's actually been done (IMO) and done for several decades. In Manufacturing, they have the 'Form, Fit or Function' "Rule" [0]. In essence, your have only a two segment part number, and the 2nd part is considered non-essential, and only for deep traceability. For software, I would apply the rule as such: 1) merge the major and minor segments, and the revision segment becomes equivalent, 2) then you follow the Form, Fit or Function rule and apply it to the core product, programs, and APIs. [0] http://www.arenasolutions.com/resources/articles/form-fit-function/ http://www.arenasolutions.com/resources/articles/form-fit-fu... [1] http://www.buyplm.com/plm-good-practice/plm-software-part-revision-form-fit-function.aspx http://www.buyplm.com/plm-good-practice/plm-software-part-re...
- Klathmon 10y ago
  Would you be able to expand on this a bit? I'm having trouble trying to figure out the analogy to the software world. You are saying basically have just `major.revision` correct? Would this be similar to how Chrome does their versioning?
  - oso2k 10y ago
    In short, yes. See my other response here [0]. [0] https://news.ycombinator.com/item?id=12792868 https://news.ycombinator.com/item?id=12792868
- jharger 10y ago
  I kind of get this, but what about this use case: I have software that is in production and has been for awhile. I've locked down all the versions of libraries I've used (FFF works here) and everything is running smoothly. However, a large customer requests a new feature, and I see that library X has a new version that has new features that will support development for the new customer feature. With semver, I can see that this new version is, say, 2.3.0. If I was using 2.2.x, I have at least some assurance that the API I was using before hasn't changed, so the amount of work to upgrade is likely limited to implementing new features, and not converting and re-testing older code. However, with the FFF rule, it seems that the new version would change (due to form/fit (api?] or function changing), and all I know is that this version is new, and I have no indication how much work it would be to upgrade, other than assume the worst case that existing APIs have changed. I could see why the manufacturing methods might make sense, especially in certified software... but in the wild west of web development, I have a feeling it would never catch on.
stronglikedan 10y ago
> I'd love a system that lets me view changelogs by the version "level" I want. Our MIS vendor offers this, and it's indispensable. Especially considering that each of their customers are on a different version at any given time. You select your current version, and any other version to compare it to, and it spits out a report of all the differences from the module level down to the object attribute level, all nicely separated into logical groups. Due to the complexity of the system, I couldn't imagine a successful upgrade without it.
- Klathmon 10y ago
  The data is there for projects like node. Issues are tagged with things like SEMVER-MAJOR and SEMVER-MINOR, doc, etc... It just needs a front-end to slap on there, and maybe a bit of standardization to make it easy to pull this data from not just Node's docs, but from others that adhere to it as well.

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.
- WorldMaker 10y ago
  I tried to make this very argument with a former employer. Who cares about numbers except for weird technical people? Just pick a cool marketing name and market the heck out of that that. "But we've always marketed 2.0 or 3.0..." So what? I suppose there's a small psychological benefit in a monotonically increasing number, but it doesn't really tell you anything more than "Saucy Gorilla" in terms of what is in a release. It can help you order the releases if you need to know which release came first, but you can alphabetize your codenames or even just have a lookup table for those rare times that actually matters.
  - isaacaggrey 10y ago
    Ubuntu is an example of doing both an increasing number (by year.month) and marketing name. Recently: 16.10 (Yakkety Yak), 16.04 (Xenial Xerus), etc. However, it seems Canonical keeps the codename out of their official press release: https://insights.ubuntu.com/2016/10/13/canonical-releases-ubuntu-16-10/ https://insights.ubuntu.com/2016/10/13/canonical-releases-ub...
Jarwain 10y ago
I've always thought of a major release as being one that isn't backwards compatible/include breaking changes
- Ajedi32 10y ago
  Yes, that's exactly what it means for any project using [SemVer](http://semver.org/ http://semver.org/). It says nothing about how many new features you added or anything like that, only that you introduced breaking changes.
franciscop 10y ago
What I do is keep bundling things together in a dev branch for a while and wait until I have to introduce a breaking change to release it all as a major version. Of course only with smaller projects where a new feature might be 3-4h of work, I cannot think Node.js waiting to introduce new features just for doing a marketing stunt. Example: https://github.com/umbrellajs/umbrella/milestone/8?closed=1 https://github.com/umbrellajs/umbrella/milestone/8?closed=1

oso2k 10y ago

It's actually been done (IMO) and done for several decades. In Manufacturing, they have the 'Form, Fit or Function' "Rule" [0]. In essence, your have only a two segment part number, and the 2nd part is considered non-essential, and only for deep traceability. For software, I would apply the rule as such: 1) merge the major and minor segments, and the revision segment becomes equivalent, 2) then you follow the Form, Fit or Function rule and apply it to the core product, programs, and APIs. [0] http://www.arenasolutions.com/resources/articles/form-fit-function/ http://www.arenasolutions.com/resources/articles/form-fit-fu... [1] http://www.buyplm.com/plm-good-practice/plm-software-part-revision-form-fit-function.aspx http://www.buyplm.com/plm-good-practice/plm-software-part-re...

Klathmon 10y ago
Would you be able to expand on this a bit? I'm having trouble trying to figure out the analogy to the software world. You are saying basically have just `major.revision` correct? Would this be similar to how Chrome does their versioning?
- oso2k 10y ago
  In short, yes. See my other response here [0]. [0] https://news.ycombinator.com/item?id=12792868 https://news.ycombinator.com/item?id=12792868
jharger 10y ago
I kind of get this, but what about this use case: I have software that is in production and has been for awhile. I've locked down all the versions of libraries I've used (FFF works here) and everything is running smoothly. However, a large customer requests a new feature, and I see that library X has a new version that has new features that will support development for the new customer feature. With semver, I can see that this new version is, say, 2.3.0. If I was using 2.2.x, I have at least some assurance that the API I was using before hasn't changed, so the amount of work to upgrade is likely limited to implementing new features, and not converting and re-testing older code. However, with the FFF rule, it seems that the new version would change (due to form/fit (api?] or function changing), and all I know is that this version is new, and I have no indication how much work it would be to upgrade, other than assume the worst case that existing APIs have changed. I could see why the manufacturing methods might make sense, especially in certified software... but in the wild west of web development, I have a feeling it would never catch on.

stronglikedan 10y ago

> I'd love a system that lets me view changelogs by the version "level" I want. Our MIS vendor offers this, and it's indispensable. Especially considering that each of their customers are on a different version at any given time. You select your current version, and any other version to compare it to, and it spits out a report of all the differences from the module level down to the object attribute level, all nicely separated into logical groups. Due to the complexity of the system, I couldn't imagine a successful upgrade without it.

Klathmon 10y ago
The data is there for projects like node. Issues are tagged with things like SEMVER-MAJOR and SEMVER-MINOR, doc, etc... It just needs a front-end to slap on there, and maybe a bit of standardization to make it easy to pull this data from not just Node's docs, but from others that adhere to it as well.