Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we’re switching to calendar versioning

cockroachlabs.com

Post reply on HN
Print view View original

31–40 of 167 posts

Re: Why we’re switching to calendar versioning

#31

Post by jniedrauer »

lugg wrote: post #26
jniedrauer wrote: post #10

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…

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

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

Re: Why we’re switching to calendar versioning

#32

Post by y0ghur7_xxx »

mcdee wrote: post #7

> 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 r…

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

Re: Why we’re switching to calendar versioning

#33

Post by mrspeaker »

jazoom wrote: post #8

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

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"!

Re: Why we’re switching to calendar versioning

#34

Post by simula67 »

mcdee wrote: post #7

> 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 r…

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

Re: Why we’re switching to calendar versioning

#36

Post by lukecameron »

kolinko wrote: post #17
jazoom wrote: post #8

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

Half the planet, but 90% of population, and probably 95% of users.

I think the problem isn't the % of population that lives in a particular hemisphere, it's that the seasonal versioning scheme forces you to think about which hemisphere the software was created in. I'd say most users of an open source database would be aware that there is software being written in South Africa, Australia, New Zealand etc.

Re: Why we’re switching to calendar versioning

#37

Post by knz42 »

jazoom wrote: post #8

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

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

The season name will only be produced in marketing materials mainly targeting North America and Europe. The technical product will be named "19.1". The season name will not appear in an install.

Re: Why we’re switching to calendar versioning

#38

Post by andrewingram »

lifthrasiir wrote: post #11
mcdee wrote: post #7

> 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 r…

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 u…

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.

Re: Why we’re switching to calendar versioning

#40

Post by knz42 »

misterdoubt wrote: post #18
devmop wrote: post #5

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.

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

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.

Post reply on HN