Hacker News Reader

Comment by stabbles | Hacker News Reader

Bumping the major version for fun is actually a pain, since configure scripts set upperbounds on major versions to be future-proof, anticipating breaking changes. Now it's just another edge case to deal with, and old versions of curl-dependents to patch.

View on HN

I thought the 8.0.0 was justified by dropping support for platforms without 64-bit integer types?

Dropping support for a group of platforms is definitely something I'd consider a breaking change.

I do not consider that a breaking change because they are no longer supported. Prior versions of the application will still run. Breaking changes to me are at the API level for SUPPORTED platforms.

But it would break builds for those platforms, and unless the change was marked as breaking, they would be silently incorrect and/or need to go and implement special-casing on the versions in their build systems as the parent comment said.

I think that's a breaking change by most definitions.

In fact, it does break builds. I've seen it personally with several Go libraries: they drop support for e.g. Go 1.12 in some minor version and then suddenly "go install ./..." step in your CI stops to work. And since we're talking about Go 1.12, that is, pre-module days, fixing that entailed either a) upgrading your whole project to use modules; b) changing the build pipeline to explicitly check out the last working version of the library's repository into GOPATH in the pre-build step.

This is particularly nasty when it happens in mostly stable, rarely-updated internal projects because what was supposed to be a 5-minute, 3-line update turns into a several hours long wrangling match. Apparently, the code does rot and rust or something.

Typically removing support for a platform is considered breaking, because users on those platforms can still run the previous versions, but cannot upgrade beyond the point where support was dropped. Very commonly seen in various Node libraries dropping support for old LTS releases coming out of support, for example.

Removing support for a platform is 100% a breaking change, regardless of the circumstances or reasoning.

Prior versions did not get their version bumped...

I'd rather deal with that than the team at Google who maintains the grpc Go library who are more than fine breaking the public API in minor changes.

https://github.com/grpc/grpc-go/issues/3798

If you read the first comment, you’ll see the API was documented as being experimental.

https://github.com/grpc/grpc-go/issues/3798#issuecomment-670...

I'm clearly in the camp of "you can add and depreciate (experimental) features all you like in minor versions, but you should only remove them in major versions" camp.

See the discussion on semver and experiments: https://github.com/semver/semver/issues/238

That's the rule for normal features, that would mean there is no meaningful difference between stable and experimental parts of an API.

Hyrum’s law. Rust mostly gets around this by requiring you run the nightly compiler and library in addition to explicitly opting into experimental pieces.

That's only true for a small portion of software released. I have an idea about where this fixation in semver comes from, but I can't really believe that everyone here is a web dev who wasn't around before semver started getting traction.

It isn’t “for fun”.[1] The project apparently just doesn’t support the versioning scheme that you allude to.

If you want this project to use a particular versioning scheme then you should just argue for that directly.

[1] Other than this snippet :) : “on curl’s 25th birthday made it extra fun”

Reply on news.ycombinator.com