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

161–167 of 167 posts

Re: Why we’re switching to calendar versioning

#161

Post by wtmt »

united893 wrote: post #50
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.

Apologies for being pedantic, but nearly 90% of the world's population lives in the Northern Hemisphere, which also holds most of the land as well. I'd say they're only 10% off

India officially has four seasons, but they are winter, summer, monsoon and post-monsoon (autumn). Depending on the place, the year may also have six seasons of two months each. [1] In general conversations, you may find people talking about summer and winter, with a sprinkling of rainy season, and not much about others.

So any definition that goes by some restricted American version (as pointed out by people living in the U.S. here) of seasons is not really applicable to 90% of the world's population. As you dig deeper into the climate of different countries, states/provinces, regions, etc., you may probably find your 90% figure drop to 10% or less.

[1]: https://en.wikipedia.org/wiki/Climate_of_India#Seasons

Re: Why we’re switching to calendar versioning

#162

Post by paulddraper »

lugg wrote: post #153
paulddraper wrote: post #150

Earlier quoted context omitted.

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

Support for the old version comes in minor/patch releases.

Re: Why we’re switching to calendar versioning

#163

Post by a1369209993 »

knz42 wrote: post #159
a1369209993 wrote: post #128

Earlier quoted context omitted.

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

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.

Re: Why we’re switching to calendar versioning

#164

Post by doubleunplussed »

mping wrote: post #73
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

University semesters are also out of phase between the hemispheres. 1st semester is ~late summer/early autumn for both.

Re: Why we’re switching to calendar versioning

#165

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

Re: Why we’re switching to calendar versioning

#166

Post by zapzupnz »

knz42 wrote: post #37
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 prod…

> in marketing materials mainly targeting North America and Europe

Except that the rest of the world sees the exact same internet and the services are available online through the world wide web, something anybody from anywhere (barring cenorship) can see.

Even if Cockroach Labs delivers a different website to people outside North America and Europe that don't reference the seasons, the rest of the world will still manage to happen upon either those materials of other people who reference the naming scheme used by those materials.

Why not save the hassle and just not bother with the season naming at all? There's enough evidence from the comment section to show such a scheme was insufficiently thought through for an internationally-available product available online that likely has an international community of users who will very likely chat amongst themselves, referencing marketing material not intended for everybody's consumption.

Re: Why we’re switching to calendar versioning

#167

Post by pvinis »

lugg wrote: post #135
sametmax wrote: post #65

Earlier quoted context omitted.

You assume software is perfect and people don't make mistake. Breaking compat on accident happens. Bad pushes and releases exist. Unpatched bugs in latest. Wrong deployments. Semver make it easier to spot/prevent mistakes by giving you more granular information. It's not like it's a data overload, so "too much info" as argument is really weird. Purity in computing is a terrible master.

> Breaking compat on accident happens. Semver would be what? Tests should catch it. Mine or yours. > Bad pushes and releases exist. Semver would be what? Tests should catch it. Mine or yours. > Unpatched bugs in latest. Semver would be what? Tests should catch it. Mine or yours. > Wrong deployments. Semver would be what? Tests should catch it. Mine or yours. > Semver make it easier to spot/prevent mistakes by giving…

One level is great and enough. Version X is nice.

Oh you care about breaking changes? Ok then for you we will have two levels. Version X.Y it is. For the person above that doesn't care about breaking, two levels still work.

What? You want to show your audience/clients/users that an update contains something interesting for them like a feature, and separate it from a simple typo-fix release? I guess we are adding another level then. Version X.Y.Z is here.

You see, semver is not the ideal way for everyone, but it's the way that everyone can use as they want. As a receiver of a version, you can care about if it's a feature or no, breaking or no, and you set your requirement to a specific number, or ^a number or ~a number etc. As a creator of a version, in order for everyone to work with semver the way they like it, we should be good citizens and try to signify what this version has. Even if you don't care about breaking changes or showing if you just added a feature, try to signify it in your version string. It will help someone.

Post reply on HN