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

111–120 of 167 posts

Re: Why we’re switching to calendar versioning

#111

Post by paulryanrogers »

insulanian wrote: post #97
paulryanrogers wrote: post #27

Earlier quoted context omitted.

Why not?

Because a backward incompatible change can be required to implement a small feature or even fix a bug, which does not justify major version bump from the production life cycle perspective.

What about the "production life cycle perspective" requires that major version numbers not bump in those cases?

If version pattern is thought of as "compatibility.feature.fix" then there is no reason that feature and fix changes cannot also bump the right most number [as compatibility is broken].

EDIT: for clarity

Re: Why we’re switching to calendar versioning

#112

Post by ThePadawan »

Vendan wrote: post #98
ThePadawan wrote: post #20

Earlier quoted context omitted.

Interesting! If I worked on a product that was version 2.1 when I started, and 5 years later was on version 6.5 without any actual rewrites or improvements in it, I would find that just as demotivating.

If I worked on something for 5 years with no rewrites/improvements, I'd be demotivated as crap, no matter the version number...

Realistically, I think there are a lot of people working in these sorts of situations.

Such a stable environment would leave a lot of room for side projects on a stable paycheck, or getting some extracurricular qualifications.

Re: Why we’re switching to calendar versioning

#113

Post by bigdubs »

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.

Just adding context in case people thought the populations were roughly equivalent. It has bearing in the validity of choosing something the majority of people would understand.

Re: Why we’re switching to calendar versioning

#115

Post by paulddraper »

web007 wrote: post #76
djsumdog wrote: post #9

Earlier quoted context omitted.

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

But the journey from A to B to C to D is longer than A to D.

You can get whiplash from conforming to every change in the winds.

Re: Why we’re switching to calendar versioning

#117

Post by Izkata »

TeMPOraL wrote: post #79
foobarbazetc wrote: post #68

Earlier quoted context omitted.

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

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

At least in the part of the US I'm from, we only used "Fall" for "Autumn", because colloquially it was already defined as a simple and pretty tight (but often slightly different each year) period: When the leaves on trees have changed color, but not yet all fallen off.

Re: Why we’re switching to calendar versioning

#118

Post by Vendan »

ThePadawan wrote: post #112
Vendan wrote: post #98

Earlier quoted context omitted.

If I worked on something for 5 years with no rewrites/improvements, I'd be demotivated as crap, no matter the version number...

Realistically, I think there are a lot of people working in these sorts of situations. Such a stable environment would leave a lot of room for side projects on a stable paycheck, or getting some extracurricular qualifications.

Yeah, and I've been in a similar situaton. A year in, and my wife told me I needed to get a new job cause that one was making me "depressed"

Re: Why we’re switching to calendar versioning

#119

Post by erik_seaberg »

paulddraper wrote: post #115
web007 wrote: post #76

Earlier quoted context omitted.

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

But the journey from A to B to C to D is longer than A to D. You can get whiplash from conforming to every change in the winds.

This. Skipping B and C needs to be managed like any other technical debt, but it can pay off. It's not your job to regression test every intermediate version of everyone's libraries.

Re: Why we’re switching to calendar versioning

#120

Post by cwilkes »

Certhas wrote: post #83
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.

It seems like in this case you want to version API and program separately. API changes aren't the only thing people care about or that should be communicated in a version number. So semver would not just be "not perfect" but be actively misleading.

Then have a semver for the two different parts.

Ie “version 3.3.1 of Awesome Server supporting the 2.x api as well as 3.1.x”

Post reply on HN