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

131–140 of 167 posts

Re: Why we’re switching to calendar versioning

#131

Post by craftyguy »

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.

Re: Why we’re switching to calendar versioning

#132

Post by Dayshine »

knz42 wrote: post #40
misterdoubt wrote: post #18

Earlier quoted context omitted.

Yes! Semver is very precisely specified and the specification ain't very long. How on Earth could they mess it up?

A point not highlighted in OP article is that Enterprise customers are shy to upgrade to a "next major version" because they will _assume_ there are breaking changes in there (even though semver allows bumping the major number without breaking changes). Calver side-steps this user bias.

>Calver side-steps this user bias.

Well, no, it just means users won't update at all, because every version could be breaking...

Re: Why we’re switching to calendar versioning

#133

Post by camgunz »

Semver really isn't good for anything. Do you trust it so much you'd deploy patch increments to prod without tests? Minor increments?

I've said it before: software is too complex to be described by three numbers. Write tests and read the changelog. The version doesn't matter at all.

Re: Why we’re switching to calendar versioning

#134

Post by teddyh »

AnIdiotOnTheNet wrote: post #58
tyingq wrote: post #41

Earlier quoted context omitted.

Marketing will, of course, do whatever they want. 3.x, 95, 98, ME, XP, NT, Vista, 7, 8, 10. Or just change the name when they want, ala macOS. Edit: added Vista... thanks!

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.

XBox Origin

Re: Why we’re switching to calendar versioning

#135

Post by lugg »

sametmax wrote: post #65
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?

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 you more granular information.

None of those things are fixed by semver. What is the point of semver again?

The only thing I, as a user, give any crap about is breaking change. i.e. major version numbers.

So why not just have one or two levels?

Re: Why we’re switching to calendar versioning

#136

Post by xg15 »

So, because of a hypothetical concern that semver could unnecessarily declare a non-breaking change as breaking, they got rid of non-breaking changes altogether?

This seems a pretty roundabout way to tell users they don't want to be backwards compatible anymore.

Re: Why we’re switching to calendar versioning

#137

Post by lugg »

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…

> 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 way forward, this is some next level idiotic shit.

> I agree that breaking compatibility should be avoided, but it shouldn't be completely out of the question.

Why not? What in your world view makes this OK? I'm using your software because it solves a problem. I'm not using it so you can make more work for me.

If linux can make backwards compat guarantees since 0.1 then so can libraries like leftpad.

> It needs to be frequent enough that your anticipate it, but not so frequent that you lose users.

Jesus christ, if you think of your users like this I don't think you really deserve them. Your users are why your thing exists, be grateful and stop shitting on their needs for stability.

Re: Why we’re switching to calendar versioning

#138

Post by pvinis »

codetrotter wrote: post #77
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…

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…

I think the key part of your answer is "IMO". Incrementing the major without breaking is still semver, where wether you think so or not. One example for you is a package that was javascript and moved to typescript. Same everything, but they increment the major.

Re: Why we’re switching to calendar versioning

#139

Post by lugg »

jniedrauer wrote: post #31
lugg wrote: post #26

Earlier quoted context omitted.

What is the point of a reproducible build if you need to rebuild it to test its the same?

The entire point of a reproducible build is that you can rebuild it to test that it's the same.

No.. the entire point of a reproducible build is so that you can rebuild the same thing given the same inputs across the world different servers.

Testing that md5sum(software A) works just like md5sum(software A) is just pointless?

Post reply on HN