Why we’re switching to calendar versioning

This feels like the "product version" has taken over again.

I promote semver internally primarily for wiring together build automation. But I also try to make it clear that there can be a _completely different_ "product version" that can mean whatever the hell we want it to be. Calendar versions are great product versions.

Many people, frequently product managers, are very uncomfortable with this distinction.

So many places use the product version as "the version", which then becomes the main justification for monolithic version control, even for distributed applications or multiple product lines. So now, you re-build and/or re-deploy everything, even things that had no changes, purely to stay in sync with "the version".

There are usually good _technical_ reasons for monolithic version control, but doing it just to slap a product version on everything usually ends up with an alarming amount of waste.

Trick question: was the startup successful?

Not that I agree with ditching semver, but the way you stated it actually sounds like a good argument for doing it, not against. Sometimes marketing people have a point.

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.

Seems like most folks here are missing the really interesting part about the article: > But was this enough of a value jump to merit the leap to 3.0? Semver said nothing about "value". Semver only talks about breaking changes and added functionality vs. purely fixing bugs. For many users and libraries this is more than sufficient, because it allows you to manage risk when upgrading. However, lets enter some false preconceptions and more importantly Enterprise:

False preconceptions: Historically major versions of software, pre-semver, had major new features. Many people still have the expectation that this will be the case. This still gets reinforced by many software products (as opposed to libraries). We'd all be surprised if Apple released a new iOS major version and it has no new significant features, but just breaks some APIs that had been deprecated. This is what server would dictate, but would break human expectations.

Enterprise: I am sure CockroachDB has support contracts with some larger companies. What are the terms? Are there some support durations that are based on major version numbers? Now majors aren't free anymore. Even if their support contracts don't care about major vs minors, you want your customers to upgrade ASAP, because the older the version you have to support, the more different is that code base from what you are actively working on and the fewer other customers will benefit. A fix on your latest version will likely be with the product forever, whereas a fix on a version that's three years old might not even be relevant to your latest. A major release in server has per definition breaking changes. So this won't be a zero-cost upgrade. Many enterprises in addition have much heavier procedures to upgrade a major dependency, especially for something like a database. This makes for a lot of reason not to upgrade. So now you need some very good carrots to get users to upgrade.

Even if you don't have paying customers, breaking changes without a big carrot can be a problem. Nobody wants a mess like Python 2.7 vs. 3.

It seems like CockroachLabs just has passage of time make the decision for them now. I'd be very curious to see how this will impact how far behind latest their customers will be.

This could easily be solved by something along the lines of “Version 3.0 maintains full compatibility with Version 2.2” at the top of their release notes.

I dislike the idea of going away from SemVer just for marketing purposes. At least as a user when I’m going to upgrade versions then I could see that “oh, this version doesn’t break compatibility”