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

151–160 of 167 posts

Re: Why we’re switching to calendar versioning

#151

Post by paulryanrogers »

insulanian wrote: post #142
paulryanrogers wrote: post #122

Earlier quoted context omitted.

In Semver the second part communicates features, not 'major'. So magnitude of the features should not matter. Unless version is more for marketing than communicating the precise nature of the changes.

That's why I'm saying semver is not a good fit for product versions. It's too technical and doesn't fit well with PR, marketing and product management.

Point taken. I'm curious if using the second/feature part of SemVer for the advertised product version would be a workable compromise?

Or must marketing always get "top billing" in that precious left-most spot?

Re: Why we’re switching to calendar versioning

#152

Post by paulddraper »

ClassyJacket wrote: post #86
bigdubs wrote: post #75

Earlier quoted context omitted.

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

Who cares unless literally all of them do.

For the same reason that software documentation is almost always in English.

Re: Why we’re switching to calendar versioning

#153

Post by lugg »

paulddraper wrote: post #150
lugg wrote: post #137

Earlier quoted context omitted.

> People ignore deprecation warnings, so the best way forward is often to break compatibility. People don't ignore deprecation warnings, they vehemently disagree with their existence. Why the fuck are you taking functionality away from me? Don't like your thing? Make a new one. The old one isn't hurting you. And if it is, make a new one. > the best way forward is often to break compatibility. This is NEVER the best w…

> Don't like your thing? Make a new one. The old one isn't hurting you. And if it is, make a new one. That is literally what a version is.

Yea except you lock your users at an old version, for what?

Are you supporting old versions?

You don't have to break backwards compat to release new stuff.

It takes some serious design flaws to create a situation where you need more than a handful of foo2 and foo can't be augmented with sane defaults for whatever new side effect is created by foo2.

Re: Why we’re switching to calendar versioning

#154

Post by infogulch »

craftyguy wrote: post #131
infogulch wrote: post #95

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…

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

I thought it was clear enough that I meant:

> So the new version would be 19.1 [API 2.2]

Re: Why we’re switching to calendar versioning

#155

Post by joeax »

mrspeaker wrote: post #33
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 f…

Not only that, but the seasons have different meanings to different people depending on where in the USA you live. In my hot and desert climate spring means late February, but in Minnesota it could mean mid-May.

When you see a season mentioned in American marketing it basically means they have no idea. If a company says "spring 2019" it could mean sometime in April, or on June 20, hours before the summer solstice.

Re: Why we’re switching to calendar versioning

#156

Post by trickstra »

StavrosK wrote: post #46
y0ghur7_xxx wrote: post #32

Earlier quoted context omitted.

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

By that interpretation, their calendar versioning (19.1.0) is also valid semver, because there's no rule about NOT just incrementing whatever whenever.

true, but doing that makes no sense, because people who made their software depend on major v18 are not switching automatically, because they first need to check if any breaking changes happened and if they need to modify their own software. Semver is "semantic" for a reason - to simplify this daunting task. Increasing major version even when there are no breaking changes is technically still semver, but without the helpful warranty, so it completely misses the point

Re: Why we’re switching to calendar versioning

#158

Post by fgonzag »

stonogo wrote: post #103
sametmax wrote: post #13

Earlier quoted context omitted.

I read that as "the problem with semver is it's not perfect". Well yeah. But no semver is worse: upgrading is hard enough when devs communicate on what breaks, but when they don't, it's just a nightmare. Semver get 80% of the job done. The 20% will still suck but Pareto and I agree that it's a pretty good deal given the effort.

You should be reading it as "the problem with semver is that it does not solve the problem it purports to solve." An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business." From a risk-management perspective, at least calendared versioning implies that you'll have to do your own homework on which upgrades are incompatible, which is at least more honest…

> An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business."

Maybe if you deploy directly to production before any testing is done.

Re: Why we’re switching to calendar versioning

#159

Post by knz42 »

a1369209993 wrote: post #128
knz42 wrote: post #44

Earlier quoted context omitted.

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

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

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

Re: Why we’re switching to calendar versioning

#160

Post by jspash »

donmcronald wrote: post #124
codetrotter wrote: post #77

Earlier quoted context omitted.

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…

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

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.

Post reply on HN