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

141–150 of 167 posts

Re: Why we’re switching to calendar versioning

#141

Post by kakwa_ »

pvinis wrote: post #138
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…

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.

Sometimes, it makes sense to increment MAJOR for a significant change, like a complete rework of the code, even if it's purely internal and doesn't break the API. In such cases, even if nothing is supposed to change "on paper", it will probably have an impact (different performance, lower stability for the few first MINORs/PATCHs, etc).

But incrementing MAJOR on a yearly basis, if the major only changes by year, doing dep=X.* in your requirements.txt/package.json/Gemfile doesn't make much sense, if one of my dependencies has not significantly changed, why should I increase a version number in my dependency manager? It's just unnecessary work.

It can also raise interesting existential question if you have to release a version with a breaking change (let say, a security fix that necessitate a change in the API). What do you do then? If you don't increase MAJOR, you don't follow semver, if you increase it, you break your versioning pattern, and release 20.0 in 2019.

Re: Why we’re switching to calendar versioning

#142

Post by insulanian »

paulryanrogers wrote: post #122
insulanian wrote: post #102

Earlier quoted context omitted.

Also, major new feature, even though it is backward compatible, is a better reason for major version number increase.

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.

Re: Why we’re switching to calendar versioning

#144

Post by jrochkind1 »

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…

Yes, it means X+1 is backwards compatible with X so long as no deprecation notices were produced by your use in X. I get it, and find it reasonable.

Re: Why we’re switching to calendar versioning

#145

Post by insulanian »

paulryanrogers wrote: post #111
insulanian wrote: post #97

Earlier quoted context omitted.

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

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

Let's say you just finished a big campaign, promoting the new major version of the software (e.g. 2.0) to customers. After starting with rollout, couple of weeks down the line shit happens (it does happen) and you realise you have a bug, which you can only fix by introducing backward incompatibility and providing e.g. a migration tool to apply the fix and migrate data.

Now according to semver you would have to release version 3.0 with basically one change, which is something that product management will not accept (and rightly so), because next big release and marketing campaign would have to be for version 4.0, and customers will ask "what the heck happened with version 3.0".

Long story short, semver is "too automatic" to fit in product management, but it is a good fit for package managers and libraries where this is less obvious to the end user.

Re: Why we’re switching to calendar versioning

#146

Post by insulanian »

paulryanrogers wrote: post #111
insulanian wrote: post #97

Earlier quoted context omitted.

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

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

We think about it as "product(Management)Version.developmentIteration.emergencyPatch".

First number is incremented only in coordination with business/PR/marketing.

Second number is incremented after every development iteration (mostly one, but sometimes multiple sprints), regardless of new features being introduced or just code stabilisation is being worked on, and regardless of it being backward compatible or not. As someone mentioned, release notes are there to communicate that part.

Third number is incremented only if we're fixing some emergency issue on one of the release branches. E.g. customer running version 4.2, reports a bug. We fix it on the branch and release 4.2.1

Re: Why we’re switching to calendar versioning

#148

Post by paulryanrogers »

insulanian wrote: post #145
paulryanrogers wrote: post #111

Earlier quoted context omitted.

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

> What about the "production life cycle perspective" requires that major version numbers not bump in those cases? Let's say you just finished a big campaign, promoting the new major version of the software (e.g. 2.0) to customers. After starting with rollout, couple of weeks down the line shit happens (it does happen) and you realise you have a bug, which you can only fix by introducing backward incompatibility and p…

> Let's say you just finished a big campaign, promoting the new major version...

Again, this sounds like a marketing concern. A software or service need not be marketed by the technical version. As mentioned elsewhere Java famously promotes it's dot version and is famously maintains backwards compatibility to v1.0, IIRC.

Consider that a business consuming software and services is not only concerned with the market version/edition but their IT very much cares about the technical version and what each release communicates. Windows has an internal version number besides the ME, XP, Vista bullshit.

Re: Why we’re switching to calendar versioning

#149

Post by paulryanrogers »

insulanian wrote: post #146
paulryanrogers wrote: post #111

Earlier quoted context omitted.

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

> 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]. We think about it as "product(Management)Version.developmentIteration.emergencyPatch". First number is incremented only in coordination with business/PR/marketing. Second number is incremented after every development iteration (most…

Then you don't have SemVer but some Frankenstein combination of marketing and technical versioning. One with few advantages to traditional, arbitrary versioning which still requires IT digest every releases' changes to get a sense of the magnitude of the changes.

Not saying that's wrong for everyone. But I for one prefer versioning that clearly communicates compatibility before any marketing concerns.

Re: Why we’re switching to calendar versioning

#150

Post by paulddraper »

lugg wrote: post #137
beatgammit wrote: post #52

Earlier quoted context omitted.

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

Post reply on HN