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

71–80 of 167 posts

Re: Why we’re switching to calendar versioning

#71

Post by Pfhreak »

beatgammit wrote: post #52
lugg wrote: post #30

Earlier quoted context omitted.

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?

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

Then it should be a major version change, right?

Re: Why we’re switching to calendar versioning

#72

Post by tyingq »

ovao wrote: post #66
AnIdiotOnTheNet wrote: post #58

Earlier quoted context omitted.

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.

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

"with Office 365 integration"

Re: Why we’re switching to calendar versioning

#73

Post by mping »

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.

Just read it as 1st or 2nd semester. Works in all hemispheres

Re: Why we’re switching to calendar versioning

#74

Post by NullPrefix »

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

Re: Why we’re switching to calendar versioning

#75

Post by bigdubs »

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.

I'm not conding the spring/summer naming (personally I'd just leave it at january/june), but the bulk of the world's population lives in the northern hemisphere, and not by a little, by a lot.

http://www.radicalcartography.net/index.html?histpop

Re: Why we’re switching to calendar versioning

#76

Post by web007 »

djsumdog wrote: post #9
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 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.

Re: Why we’re switching to calendar versioning

#77

Post by codetrotter »

y0ghur7_xxx wrote: post #32
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 NO…

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.

Re: Why we’re switching to calendar versioning

#78

Post by username223 »

NullPrefix wrote: post #74
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 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.

Re: Why we’re switching to calendar versioning

#79

Post by TeMPOraL »

foobarbazetc wrote: post #68
edanm wrote: post #56

Earlier quoted context omitted.

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.

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.

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.

Re: Why we’re switching to calendar versioning

#80

Post by gtirloni »

knz42 wrote: post #47
tamentis wrote: post #24

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.

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.

And not much else.
Post reply on HN