Why we’re switching to calendar versioning
cockroachlabs.com
Why we’re switching to calendar versioning
1–10 of 167 posts
Re: Why we’re switching to calendar versioning
#2If semver says the next version is 2.2, then it's 2.2, what discussion is there to side step?
Re: Why we’re switching to calendar versioning
#3I never found stric following of semantic versioning to be a good fit for product versions. It makes sense only for libraries and packages.
Re: Why we’re switching to calendar versioning
#4If semver says the next version is 2.2, then it's 2.2, what discussion is there to side step?
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.
Re: Why we’re switching to calendar versioning
#5Why 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.
Re: Why we’re switching to calendar versioning
#6It should really be called Pedantic Versioning. Pedver for short.
Re: Why we’re switching to calendar versioning
#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 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.
Re: Why we’re switching to calendar versioning
#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.
Re: Why we’re switching to calendar versioning
#9> 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 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.
Re: Why we’re switching to calendar versioning
#10The 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.