4 ms·
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 inde
by 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 agoYou 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 agoI 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 agoUbuntu 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 agoI've always thought of a major release as being one that isn't backwards compatible/include breaking changes
- Ajedi32 10y agoYes, 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 agoWhat 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