
Why we’re switching to calendar versioning - tosh
https://www.cockroachlabs.com/blog/calendar-versioning/
======
mcdee
> Among other things, it includes a cost-based optimizer that can complete the
> TPC-H benchmark, CDC, and two major enterprise security features. But was
> this enough of a value jump to merit the leap to 3.0? Or was this a 2.2?
> Strictly following the semantic versioning rules would specify 2.2, as there
> are no backwards incompatible API changes. But with that logic guiding the
> major version bump, we could potentially remain on 2.x forever.

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.

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. Sounds like a
triumph of marketing over useful information.

~~~
y0ghur7_xxx
> 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.

~~~
codetrotter
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.

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

~~~
jspash
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.

------
jazoom
> Since we release on a 6 month cadence, we’re starting to name releases by
> season and year, which means our next release is now CockroachDB Spring ‘19.

Ugh. You'd think the creators of a multiregion database would realise half the
planet has Autumn the same time as the other half has Spring.

> It also eliminates the mental gymnastics needed to figure out how old a
> release is

I guess not.

~~~
mrspeaker
Best thing about moving to the US was that all those phrases "coming summer
2019" actually make sense! In Australia we don't really use seasons as
references (the seasons aren't as distinct as they are here) - and because
they were then flipped as well I never really thought they had a real meaning.

I guess I must have known they did have a real meaning, but my "consumer"
grasp of them was more like vague marketing fluff that meant "will probably be
out eventually"!

~~~
edanm
What a brilliant observation, I love finding things like that where you never
really thought consciously about something.

I'm similar to you, though I don't even have the excuse of living with
different seasons - I just never really thought about it.

~~~
foobarbazetc
As an also-Australian, my brain just doesn’t process seasons like Americans.

If someone says “coming in the Spring” I literally have no idea when that is.
The dates of seasons are meaningless.

~~~
TeMPOraL
As a Polish person, my brain hates these too, even though we have proper
seasons here. When I see "coming in the Spring", my mind is all "that's 20-ish
of March, I think... or maybe April... no, December is definitely winter, so
it must be March!".

Seasons are dumb. I remember reading a rant on the Internet once that
advocated that we should recognize two seasons - summer and winter. You could
put the boundary at equinoxes, with summer encompassing both traditional
summer and spring, and winter encompassing traditional autumn and winter. The
definition would be simple: summer is when it's kind of warm most of the time,
winter is when it's kind of cold most of the time. I remember this resonating
with me much more than the traditional definition.

Going back to temporal coordinates, the older I get the more confident I am in
feeling that, for terrestrial use, anything that's not an ISO 8601 date is
garbage and should not be used.

~~~
Izkata
> and winter encompassing traditional autumn and winter. The definition would
> be simple: summer is when it's kind of warm most of the time, winter is when
> it's kind of cold most of the time.

At least in the part of the US I'm from, we only used "Fall" for "Autumn",
because colloquially it was already defined as a simple and pretty tight (but
often slightly different each year) period: When the leaves on trees have
changed color, but not yet all fallen off.

------
mr_tristan
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.

~~~
CivBase
This!

Semver uses the version number to convey useful information. Getting rid of
semver just eliminates that information.

If you want to bump versions for marketting, that's perfectly valid. Just use
a separate product version.

My SVN commit numbers and git hashes also fail to convey useful marketting
information, but that's no reason to get rid of them!

------
ajmurmann
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.

------
devmop
Why not just move to 3.0? Semver only says that a breaking change MUST be an
increase to the major version. It doesn't proscribe an increase of the major
version without a breaking change.

~~~
misterdoubt
Yes! Semver is very precisely specified and the specification ain't very long.
How on Earth could they mess it up?

~~~
knz42
A point not highlighted in OP article is that Enterprise customers are shy to
upgrade to a "next major version" because they will _assume_ there are
breaking changes in there (even though semver allows bumping the major number
without breaking changes).

Calver side-steps this user bias.

~~~
AnIdiotOnTheNet
Why are developers always insistent on trying to trick the user into doing
what they want them to do, or what they think is best, instead of letting
users do what users want to do?

Users shy away from major version numbers because they are allowed to change
things in incompatible ways. When you jump a major version you're signaling
that stuff might _intentionally_ break, and they make their decisions
accordingly. The solution is not to make your communication with user even
worse!

~~~
soccerdave
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”

------
jrochkind1
> helps us (and our users) avoid the confusion around the significance of a
> release.

I think you mean "makes it impossible to know if a release includes backwards
incompatible changes without looking at the release notes, while still having
a release number say nothing about other aspects of the significance of a
release."

~~~
knz42
> I think you mean "makes it impossible to know if a release includes
> backwards incompatible changes without looking at the release notes, while
> still having a release number say nothing about other aspects of the
> significance of a release."

The compatibility guarantees of CockroachDB do not change with this. It's
always been the same: version X+1 will remain backward compatible with X but
may break compatibility with X-1. Deprecation notices for definitive changes
in version X+2 are introduced in version X.

~~~
a1369209993
> version X+1 will remain backward compatible with X but may break
> compatibility with X-1

That is literally impossible; a breaking change from X-1 to X+1 must have been
introduced in one of the intervals X-1 to X or X to X+1. It the latter, X+1
breaks compatibility, if the former, let X' = X-1 and X'+1 breaks
compatibility.

Presumably you mean that X always includes warnings about breaking changes in
X+1, which is a vast improvement on _some_ projects, but knowing that a
problem exists doesn't mean it _doesn 't_ exist.

~~~
knz42
> That is literally impossible; a breaking change from X-1 to X+1 must have
> been introduced in one of the intervals X-1 to X or X to X+1. It the latter,
> X+1 breaks compatibility, if the former, let X' = X-1 and X'+1 breaks
> compatibility.

No, that's not how it works. The deprecation is introduced in version X-1; the
new behavior is introduced but is opt-in; in version X, the new behavior
becomes opt-out; in version X+1 the old behavior is removed.

~~~
a1369209993
That breaks backwards compatibility _twice_ ; once in X when 'do_thing' breaks
and has to be rewritten as 'enable_thing;do_thing', then again when X+1 causes
'enable_thing;do_thing' to break.

------
ShorsHammer
Seems to be a few critics in here but I think a good usecase for calendar
versioning is crypto and security critical libraries.

You hear about about WPA3 being broken in April 2019. It's obvious your WPA3
18.10 lib is vulnerable, WPA3 19.04 is not.

It's a lot simpler to parse and can lead to less mistakes.

~~~
anticensor
Is it just me or are you implying WPA3 revisions should be coupled to Ubuntu
release schedule?

------
infogulch
Decoupling feature releases from API changes is the best option. Your API
follows strict semver, but your new features can use whatever versioning
scheme you want, this date-based scheme is fine.

So the new version is 19.1 [API 2.2].

Most of this thread is debating the relative value of using a single number to
communicate feature additions vs breaking changes, but these two things are
(mostly) orthogonal. _So use two numbers._ This even allows releases where
there are awesome new features but _no_ API changes at all!

~~~
craftyguy
> So the new version is 19.1 [API 2.2].

The article says they decided to 'rename' 2.2 to 19.1. There is no separate
versioning for features and API, only 1 version for everything.

~~~
infogulch
I thought it was clear enough that I meant:

> So the new version _would be_ 19.1 [API 2.2]

------
jniedrauer
The main reason I don't like timestamp based version schemes is that it makes
builds inherently difficult to reproduce.

I wrote some code for a specialized piece of equipment earlier this year. One
of the requirements on this equipment is that all package installs contain a
unique version string (ie. you can't install the same version twice). So I
based build versions on git hash and timestamp. This turned out to be a
problem because it made it impossible to reproduce builds without hacking the
build system clock. So I switched back to semver for releases.

~~~
lugg
What is the point of a reproducible build if you need to rebuild it to test
its the same?

~~~
jniedrauer
The entire point of a reproducible build is that you can rebuild it to test
that it's the same.

~~~
lugg
No.. the entire point of a reproducible build is so that you can rebuild the
same thing given the same inputs across the world different servers.

Testing that md5sum(software A) works just like md5sum(software A) is just
pointless?

------
docode
Why not simply separate versioning into product and technical like Microsoft
Visual Studio as an example: Product version: Visual Studio 2019 Technical
version: 16.0.1

It fits good for marketing and for developer people.

~~~
AnIdiotOnTheNet
Because it causes even more confusion. Given a Windows 10 version number like
10.0.16299.522, you need a lookup table to determine that it is called 1709 by
all the documentation.

------
foobarbazetc
Just so you know, season based names make no sense since the Southern
Hemisphere exists.

Also there’s no such thing as Fall in a lot of places.

~~~
ClassyJacket
As an Australian, "Coming Summer 2019" may as well just say "Coming 2019".

I don't care to research the country of the developer and then the dates that
are considered summer in that country just because they were so ignorant they
used a season as a timeframe.

------
sauceop
I feel like a lot of semver purists have never maintained software with a lot
of downstream dependencies. The gray area about what is a breaking change is
huge and it's hard to usefully improve software without making changes that
are breaking under some definitions. The broadest is that, if a downstream
program was working against version x.y, then it should always work unmodified
against x.z.

One obvious case is bug compatibility and undocumented behaviour - it isn't
that uncommon for software to depend on bugs or undocumented/unintentional
behaviour. But if you're exposing a language like SQL, it's even messier. E.g.
if cockroach added a new feature to the SQL dialect, then it could break
downstream software that was assuming a particular SQL string would return an
error. Or if you extend existing functionality, say supporting a wider range
of arguments in some function.

There's also unspecified behaviour and implementation details - e.g. if a
query without an "order by" happened to reliably return rows in a particular
order before an upgrade, but it changes after an upgrade because of an
algorithmic change, is it a breaking change? Common sense would say no,
because it's not documented behaviour, but pedants could disagree.

And of course there's performance changes - if a query runs 100x slower after
an upgrade, but returns the same result, is that a breaking change?

If you take the most pedantic interpretation of semver, you either have to
bump the major version number all the time or you are very limited in how you
can improve the software.

------
insulanian
I never found stric following of semantic versioning to be a good fit for
product versions. It makes sense only for libraries and packages.

~~~
paulryanrogers
Why not?

~~~
insulanian
Because a backward incompatible change can be required to implement a small
feature or even fix a bug, which does not justify major version bump from the
production life cycle perspective.

~~~
paulryanrogers
What about the "production life cycle perspective" requires that major version
numbers not bump in those cases?

If version pattern is thought of as "compatibility.feature.fix" then there is
no reason that feature and fix changes cannot also bump the right most number
[as compatibility is broken].

EDIT: for clarity

~~~
insulanian
> If version pattern is thought of as "compatibility.feature.fix" then there
> is no reason that feature and fix changes cannot also bump the right most
> number [as compatibility is broken].

We think about it as
"product(Management)Version.developmentIteration.emergencyPatch".

First number is incremented only in coordination with business/PR/marketing.

Second number is incremented after every development iteration (mostly one,
but sometimes multiple sprints), regardless of new features being introduced
or just code stabilisation is being worked on, and regardless of it being
backward compatible or not. As someone mentioned, release notes are there to
communicate that part.

Third number is incremented only if we're fixing some emergency issue on one
of the release branches. E.g. customer running version 4.2, reports a bug. We
fix it on the branch and release 4.2.1

~~~
paulryanrogers
Then you don't have SemVer but some Frankenstein combination of marketing and
technical versioning. One with few advantages to traditional, arbitrary
versioning which still requires IT digest every releases' changes to get a
sense of the magnitude of the changes.

Not saying that's wrong for everyone. But I for one prefer versioning that
clearly communicates compatibility before any marketing concerns.

------
dietr1ch
"But with that logic guiding the major version bump, we could potentially
remain on 2.x forever."

That's WAI if you don't break compatibility.

I think the only reason behind moving is to have a better sense of progress or
freshness. It seems like semantic versioning should support having some date
on the minor numbers.

~~~
FiddlyPack
Semver _allows_ non-breaking changes on major release. It also supports
tagging which could be a date tag.

The entire spec is like a 10 minute read. Anyone using semver should have at
least read the semver spec. Anyway, the bullet on tagging:

“Build metadata MAY be denoted by appending a plus sign and a series of dot
separated identifiers immediately following the patch or pre-release version.
Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-].
Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when
determining version precedence. Thus two versions that differ only in the
build metadata, have the same precedence. Examples: 1.0.0-alpha+001,
1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.”

------
tamentis
These decisions are often driven by marketing or product folks and rarely
engineers.

The marketing team would probably even push further toward 1, 2, 3, or
anything that could make a big splash once or twice a year. The product team
would probably prefer dates because it makes their planning easier.

~~~
knz42
Engineers like calver too! (I do.) Calver tells me very clearly how old a
release it and what was the technical landscape when it was released.

For example I know precisely how old ubuntu 16.04 is and what I can expect to
(not) be in there.

~~~
gtirloni
And not much else.

------
ses1984
If semver says the next version is 2.2, then it's 2.2, what discussion is
there to side step?

~~~
tyingq
Marketing maybe? If you are good about being backward compatible, you never
release n+1, which might be mistaken for being stale vs your competitors.

~~~
paulryanrogers
Can't marketing just focus on the minor part as Java does?

~~~
tyingq
Marketing will, of course, do whatever they want. 3.x, 95, 98, ME, XP, NT,
Vista, 7, 8, 10. Or just change the name when they want, ala macOS.

Edit: added Vista... thanks!

~~~
AnIdiotOnTheNet
XBox -> XBox 360 -> XBox One... If the next console from Microsoft is
controller that live streams games from the cloud I expect it to be called the
XBox ExBox.

~~~
ovao
And if it’s a full console, the next Xbox should be the ‘Xbox 361’. Or the
‘Xbox -359’, maybe?

~~~
tyingq
_" with Office 365 integration"_

------
deforciant
In one of the startups that I worked marketing people really wanted us to
quickly go through version 1, 2 and reach version 3 because "many corporations
aren't even looking at tools if they are not version 3 yet" :D They didn't
really care what features should be included in those versions :) Fortunately
sanity prevailed and we stayed with semver.

~~~
amenod
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.

------
vmatouch
The versionings are not mutually exclusive. In our company we use calver, it
is used mainly for planning and business purposes and works well. During the
quarter or whatever period there can be multiple semantically versioned
releases made. The only problematic is the YY format choice. Lots of people
confuse 19.3 with March 19th in our country.

------
gcb0
they had the worst reason possible. "not remain on 2.x forever".

nobody cares about stability anymore. staying on 2.x by not breaking backward
compatibility forever is a great feat to celebrate, sad to see marketing
getting the best of it.

I personally like traditional versioning + security patches by date. but I'm
on the minority.

------
xg15
So, because of a hypothetical concern that semver could unnecessarily declare
a non-breaking change as breaking, they got rid of non-breaking changes
altogether?

This seems a pretty roundabout way to tell users they don't want to be
backwards compatible anymore.

------
sergiotapia
All this means is that users will need to read changelogs to know if this
update has breaking changes. A really bad move a database provider, you're the
backbone of near all applications you should be rocksolid.

------
nakovet
> how much time has elapsed between two releases

If they really wanted to communicate that clear without having to read extra
docs they should have used 2019 version instead of 19.

> Our Spring ‘19

The world is big, bellow the line of the equator the seasons are opposite so
that could lead to more confusion to the lower half of the planet.

In summary, whatever works for them, SemVer is not the clearly the winner in
market share, so we as devs always have to check and double check when
upgrading things but IMHO the arguments provided in the article are not strong
enough to justify the move.

------
marknadal
This is a hilarious coincidence, we (a database with opposite tradeoffs of
Cockroach) just did the same thing a month ago:

`npm install gun@0.2019.413`

This means no breaking change.

How old/new of a version you are on.

Month+day the bug got fixed.

It was the compromise between intense debates within the community. It is the
one thing everyone could agree too.

Looks like it is already catching on! I hope more projects adopt it.

------
zapzupnz
'Spring' is a useless indicator for versioning. Most developers publish from
the northern hemisphere so their Spring is March through May; mine is
September through November down here in New Zealand.

Cockroach Labs should rather copy Apple's model, free of hemisphere bias:
Early 20XX, Mid 20XX, Late 20XX.

------
meej
An item about versioning is always a good time to revisit Rich Hickey's
thoughts on growing software and his criticisms of semantic versioning.

[https://www.youtube.com/watch?v=oyLBGkS5ICk](https://www.youtube.com/watch?v=oyLBGkS5ICk)

------
camgunz
Semver really isn't good for anything. Do you trust it so much you'd deploy
patch increments to prod without tests? Minor increments?

I've said it before: software is too complex to be described by three numbers.
Write tests and read the changelog. The version doesn't matter at all.

------
chiefalchemist
Seems to me, there's version and there's compatibility. They are not one in
the same. Trying to make a single field do double duty is so often never a
good idea. Why is this any different?

Perhaps it's time to rethink this?

------
tbarbugli
Bad choice. If I ever build and maintain a database I am going to managethe
vefsioning and releasing the way postgresql does, no need to get fancy with
this, keep your user happy and not busy with distractions like this.

------
nmca
This is terrible imo, but does is further evidence that semver should have a
fourth, non-semantic marketing prefix. Because otherwise people will do ...
"things" like this.

------
makecheck
I don’t see why these things need to be mutually exclusive.

For years I’ve released things with semantic numbering but a YYYYMMDD build
number.

------
scarejunba
Funny. Not everyone knows what "Spring" is. It's not the universal season you
think it is.

Definitely year.month is superior.

------
7e
It turns out semantic versioning hurts sales.

------
JabavuAdams
Wow, people really, really seem to care about this. Does it matter, or is this
just dev wanking?

------
blaisio
This made me respect cockroachdb less.

------
urvader
It’s called romantic versioning

