Kind of wish there was yet another number prefix to semver to signify this.
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.
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.
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.
However, it seems Canonical keeps the codename out of their official press release: https://insights.ubuntu.com/2016/10/13/canonical-releases-ub...
Example: https://github.com/umbrellajs/umbrella/milestone/8?closed=1
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-fu...
[1] http://www.buyplm.com/plm-good-practice/plm-software-part-re...
You are saying basically have just `major.revision` correct? Would this be similar to how Chrome does their versioning?
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.
Part Name: MY SW 2.0
Predecessor Part Number: 150000-0001
Part Number: 200000-0001
Part Name: MY SW 2.0-IBM
Predecessor Part Number: 200000-0001
Part Number: 200001-0001
Part Name: MY SW 2.0-IBM
Predecessor Part Number: 200001-0001
Part Number: 200001-0002
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.
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.
Also of note, chakra still has async/await behind a flag as well.
> 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-254...
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?"
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.
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
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
Node.js V7
Node.js V8! (denotes something significant)