> The whole point of semver is that it allows people to know if they can upgrade version without hitting incompatibilities. So yes, this would be a 2.2 and those on 2.1 would know that they could upgrade to it without worrying about fixing their own integrations.

No. Semver states quite clearly that "Major version MUST be incremented if any backwards incompatible changes are introduced to the public API.".

It does NOT state that the Major verson MUST NOT be incremented if the api has no backwards incompatible changes.

You can increment the MAJOR component of the version number at your will. So this is quit clearly a 3.0.0 release. Or it could be a 40.0.0 release and it would still be valid semver.

IMO it’s kind of implied by semver that a major version increment means breaking changes. If you increment major version without breaking changes then you aren’t really doing semver IMO.

It’s like if you have a fire alarm that goes off when there’s a fire but which also goes off randomly all of the time. People are going to stop listening to it, because even though it reliably rings when there’s a fire the fact that it rings is unlikely to mean there’s an actual fire.

In the same way, if you keep incrementing the major version without breaking changes then people can no longer rely on the version number to be alerted about breaking changes.

By all means, increment your major version number when you feel like it. Just don’t call it semver. Because even if you are technically allowed to, it goes against the spirit / point of semver IMO.

Just add an unnecessary breaking change and everything's perfect.

This is the correct answer! IMHO.

A perfect solution that strikes the balance between an engineer's unrelenting desire for correctness and the marketing departments seemingly irrational need for perceived progress.

I think the key part of your answer is "IMO". Incrementing the major without breaking is still semver, where wether you think so or not. One example for you is a package that was javascript and moved to typescript. Same everything, but they increment the major.

Sometimes, it makes sense to increment MAJOR for a significant change, like a complete rework of the code, even if it's purely internal and doesn't break the API. In such cases, even if nothing is supposed to change "on paper", it will probably have an impact (different performance, lower stability for the few first MINORs/PATCHs, etc).

But incrementing MAJOR on a yearly basis, if the major only changes by year, doing dep=X.* in your requirements.txt/package.json/Gemfile doesn't make much sense, if one of my dependencies has not significantly changed, why should I increase a version number in my dependency manager? It's just unnecessary work.

It can also raise interesting existential question if you have to release a version with a breaking change (let say, a security fix that necessitate a change in the API). What do you do then? If you don't increase MAJOR, you don't follow semver, if you increase it, you break your versioning pattern, and release 20.0 in 2019.

I agree, people shouldn't be afraid of v3.27.0

By that interpretation, their calendar versioning (19.1.0) is also valid semver, because there's no rule about NOT just incrementing whatever whenever.

Except that for it to remain both valid calver and valid semver, they would have to delay all breaking changes until January every time they come up.

They seem to indicate that they aren't expecting any more breaking changes, but yes, that's generally true.

It's not valid if 19.2 introduces breaking changes form 19.1

true, but doing that makes no sense, because people who made their software depend on major v18 are not switching automatically, because they first need to check if any breaking changes happened and if they need to modify their own software. Semver is "semantic" for a reason - to simplify this daunting task. Increasing major version even when there are no breaking changes is technically still semver, but without the helpful warranty, so it completely misses the point

The problem of semver is that everyone interprets the compatibility differently. There are some language-supported criteria, but that does not cover all important use cases. In addition, any reasonable compatibility criteria might be impossible for large enough softwares---every revision can be potentially major in the semver terminology and it won't deliver much value to the user anyway. The calender versioning is useful for such cases.

I read that as "the problem with semver is it's not perfect". Well yeah. But no semver is worse: upgrading is hard enough when devs communicate on what breaks, but when they don't, it's just a nightmare.

Semver get 80% of the job done. The 20% will still suck but Pareto and I agree that it's a pretty good deal given the effort.

You should be reading it as "the problem with semver is that it does not solve the problem it purports to solve."

An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business." From a risk-management perspective, at least calendared versioning implies that you'll have to do your own homework on which upgrades are incompatible, which is at least more honest than ineffective rigor.

Are you saying that knowing that there is an 80% starting chance of it not breaking anything is not any better not knowing that? That knowing that the devs don't think anything will break or not is worthless? And that is not counting the times when they do bump the major version to tell you it will probably break something.

The 100% solution you imply as a strawman here doesn't exist and some information is better than no information. And no one said Semver means you don't test, it just guides you on the expected behavior of the new release.

> An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business."

Maybe if you deploy directly to production before any testing is done.

An 80% solution means you have 80% fewer unexpected breakages.

I think the language-backed semver can be useful (I really want Cargo to support this mode!). The general unguided semver seems less useful.

I envision a much simplified alternative (or analogue) to the semver: there is a single decimal revision, and you should strive to be compatible back to the first revision. When you are willing to break the compatibility, you simply rename. This is similar to Go's practice but can be technically made compatible to the three-part semver (by encoding minor and patch versions to the decimal).

This is my issue with semver. I don't care about minor non breaking change, just give me the latest.

Breaking change is the only thing I want to know about so realistically I only need to worry about major version updates right?

So lib: 1.* Should be fine, right?

But it's not and when people quip well you should have pegged your versions it's like what? Maybe you shouldn't have broke backwards compat?

You assume software is perfect and people don't make mistake. Breaking compat on accident happens. Bad pushes and releases exist. Unpatched bugs in latest. Wrong deployments.

Semver make it easier to spot/prevent mistakes by giving you more granular information. It's not like it's a data overload, so "too much info" as argument is really weird.

Purity in computing is a terrible master.

> Breaking compat on accident happens.

Semver would be what? Tests should catch it. Mine or yours.

> Bad pushes and releases exist.

Semver would be what? Tests should catch it. Mine or yours.

> Unpatched bugs in latest.

Semver would be what? Tests should catch it. Mine or yours.

> Wrong deployments.

Semver would be what? Tests should catch it. Mine or yours.

> Semver make it easier to spot/prevent mistakes by giving you more granular information.

None of those things are fixed by semver. What is the point of semver again?

The only thing I, as a user, give any crap about is breaking change. i.e. major version numbers.

So why not just have one or two levels?

One level is great and enough. Version X is nice.

Oh you care about breaking changes? Ok then for you we will have two levels. Version X.Y it is. For the person above that doesn't care about breaking, two levels still work.

What? You want to show your audience/clients/users that an update contains something interesting for them like a feature, and separate it from a simple typo-fix release? I guess we are adding another level then. Version X.Y.Z is here.

You see, semver is not the ideal way for everyone, but it's the way that everyone can use as they want. As a receiver of a version, you can care about if it's a feature or no, breaking or no, and you set your requirement to a specific number, or ^a number or ~a number etc. As a creator of a version, in order for everyone to work with semver the way they like it, we should be good citizens and try to signify what this version has. Even if you don't care about breaking changes or showing if you just added a feature, try to signify it in your version string. It will help someone.

Sometimes breaking backwards compatibility is necessary. For example, if a function in a standard library has an error case that the initial version ignored (happened in Go), you can't start emitting errors when you used to guarantee that it wouldn't error. Or if there's a fundamental flaw in a function that cannot be fixed without a signature change.

People ignore deprecation warnings, so the best way forward is often to break compatibility.

I agree that breaking compatibility should be avoided, but it shouldn't be completely out of the question. It needs to be frequent enough that your anticipate it, but not so frequent that you lose users. And you should try to have a bridge between old and new versions (e.g. Rust's "editions" seem like a good idea).

Then it should be a major version change, right?

> People ignore deprecation warnings, so the best way forward is often to break compatibility.

People don't ignore deprecation warnings, they vehemently disagree with their existence. Why the fuck are you taking functionality away from me?

Don't like your thing? Make a new one. The old one isn't hurting you. And if it is, make a new one.

> the best way forward is often to break compatibility.

This is NEVER the best way forward, this is some next level idiotic shit.

> I agree that breaking compatibility should be avoided, but it shouldn't be completely out of the question.

Why not? What in your world view makes this OK? I'm using your software because it solves a problem. I'm not using it so you can make more work for me.

If linux can make backwards compat guarantees since 0.1 then so can libraries like leftpad.

> It needs to be frequent enough that your anticipate it, but not so frequent that you lose users.

Jesus christ, if you think of your users like this I don't think you really deserve them. Your users are why your thing exists, be grateful and stop shitting on their needs for stability.

> Don't like your thing? Make a new one. The old one isn't hurting you. And if it is, make a new one.

That is literally what a version is.

Yea except you lock your users at an old version, for what?

Are you supporting old versions?

You don't have to break backwards compat to release new stuff.

It takes some serious design flaws to create a situation where you need more than a handful of foo2 and foo can't be augmented with sane defaults for whatever new side effect is created by foo2.

Support for the old version comes in minor/patch releases.

> you simply rename

That sounds like an awful idea that will result in people adding version information to the name, not to mention destroying discoverability.

It seems like in this case you want to version API and program separately. API changes aren't the only thing people care about or that should be communicated in a version number. So semver would not just be "not perfect" but be actively misleading.

Then have a semver for the two different parts.

Ie “version 3.3.1 of Awesome Server supporting the 2.x api as well as 3.1.x”

I've seen this happen with Babel a few times. They've released bugfix releases which fixed a slightly incorrect implementation of a spec, which ended up breaking loads of peoples builds (this was before npm/yarn had a decent way to lock dependencies). Turns out, compilers have a really high bar for what can be considered a non-breaking change.

Generally though, I think for end user software, a "breaking" change is one that requires the user to relearn something, i.e it breaks an existing mental model.

For a standardized language like SQL you don't have API incompatibility.

Yet a cost based optimiser may break your application, completely.

Calendar Versioning prompts to update and highlights that you should test the behaviour every time, which sounds about right.

Also even a patch release of a SemVer library is allowed to be runtime incompatible. Throwing an exception on incorrect usage is down to the patch definition. It fixes incorrect (undefined) behaviour. Going from a O(1) to. O(n²) implementation to fix behaviour is also within SemVer patch level.

SemVer does not guarantee that your code will continue to work as intended after an upgrade. It only guarantees you don't have to change your code between minor versions.

They also mention in the article how they don't support skipping releases, so it sounds like you have to upgrade to each point release anyway?

Really if you're not constantly updating dependencies as part of your pipelines, you're going to quickly get into dependency rot issues.

I'm always surprised at how often developers freeze a set of versions and leave them for a lifetime. In my past three companies I have been the only one interested in pushing dependencies on a regular basis. I always start with a massive backlog, and end up having to incrementally update from the Stone Age to $today. Once that's set and tests pass it's easy to keep things up-to-date, you end up with single-digit changes every month instead of ~100 every year.

Do it this way and save yourself the pain of zillions of updates when you HAVE to bump a package for a CVE.

Yet another case of "if it hurts, do it more often"

https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...

But the journey from A to B to C to D is longer than A to D.

You can get whiplash from conforming to every change in the winds.

This. Skipping B and C needs to be managed like any other technical debt, but it can pay off. It's not your job to regression test every intermediate version of everyone's libraries.

Word! And same for me at new jobs. I also tend to be the one who writes docs, gets testing automated, CI.

Too many developers think banging out code as fast as they can is "doing their job well".

They could have picked Android's versioning scheme : a codename to signal significance and an API level to signal compatibility.

This right here. The only reason people observe tension between semantic versioning and romantic versioning is because prior to semantic versioning we spent decades conflating the version number to convey both "important new feature" and "incompatible changes". Both user marketing and technical compatibility guidance are important, but there's nothing that inherently says that both of these things need to be communicated via a single version number. Pick a nice-sounding word to market your version with big changes, and leave it unrelated to your API version.

>The calender version 19.1 tells me nothing other than when it was released, which is of no interest whatsoever when evaluating what it does.

Old is bad, new is good. What else is there to understand?

"You now have Chrome/Firefox 277, which is different from version 276, and has installed itself. Deal with it, because there's no option to revert to version 276." That's just how software works these days.