Hacker News Reader

Comment by chrismorgan | Hacker News Reader

> This is also true for ecosystems like Rust or Go, that have SemVer baked into their packaging toolchain².

> 2. […] Bumping major in Go means creating a new import path. Which is so painful that even Google is weaseling around with their own projects.

That’s not Go baking in SemVer, that’s them almost denying the existence of version numbers. (I last tried Go before go pkg was a thing, do they have version numbers in at least some shape now? Certainly they used not to.) Creating a new import path to bump major? You can do this in any ecosystem. Python, for example, has urllib, urllib2, urllib3…

So I object strenuously to this classification. Say that Rust and npm bake in SemVer, perhaps, but Go doesn’t.

View on HN

The SemVer in Rust/Cargo is pretty good with some caveats:

- Minimum Supported Rust Version doesn't play into it, and that's been a topic of debate.

- Build time dependencies don't play into (I think).

But generally the Rust ecosystem takes code stability fairly seriously and the SemVer oriented bits have done a lot of good.

It does get hairy if you try to explicitly use older versions (e.g. early minor versions of a specific major version) as Cargo tries to pick the most recent release available. I haven't much about this in practice.

Baking SemVer in and having an ecosystem-wide convention to use SemVer (which I hope will in the future be strengthened by machine-checking API compatibility and defaulting to rejecting incompatible changes) gives you sane defaults. You can still specify weird dependencies if you choose to: `foo = ">= 1.2.3, < 1.4.5"`.

I definitely wish MSRV was considered in Cargo’s resolution algorithm. This is definitely the biggest issue in Rust package versioning. But if it was, that’d leave the security arguments in play, as now you could be being silently fed an old, insecure version of a package.

TIL MSRV minimum supported rust version

https://github.com/rust-embedded/wg/blob/master/ops/msrv.md

Go only supports semantic versions, and has created quite a bit of friction if you want to use any other sort of versioning scheme (especially if it kinda looks like SemVer, such as vYEAR.WEEK.BUILD).

Pushing it even further, Go puts a gun in your mouth and makes it so that you cannot use any other version scheme but SemVer. So you either pull the trigger and deal with the pain of SemVer, or you do what growing number in the community are doing: taking the gun from their mouth and using v0 forever.

go modules was enabled by default in Go 1.16

The impression I’m getting is that Go modules have version numbers, but that the version number is basically just a sort of string where the only available option is comparing version numbers, so that there’s no resolution algorithm (e.g. “>1.16, <2”), and consequently no potential for version maintenance (which would be why major versions have to have a new URL). Semantically, then, this is no different from version numbers being just integers.

Is this correct?

This is not quite correct. Go understands `-u=patch` vs. `-u` to refer to patch vs. minor version. It also forces you to use a different path for each major version, by parsing the major version (and conversely also ignores version tags less than the path version so you can't get a "v2" path with "v1.1.3"). So it simultaneously understands semver in the "porcelain" tools, but version resolution per se is really only bounded on the low side because any upgrade preserving the path should be safe.

It's not "minor" though, `-u` just means "update it". If that happens to be v1.1.0 to v200.3.4, it'll just make that change.

The reason it's often claimed to be minor is: modules at v2 or beyond should have a different import path than v1, so they're actually a 100% different library with no implied relation to the v1 version (there may be one, but none is implied). So v2.x -> v3 will never auto-update - that'd be crazy, they're different libraries. You can even have them both installed at the same time, at different versions, node_modules-like, just like any other two different libraries.

I say "should" because it's not enforced - if you ignore this and just tag a v200.3.4 with no v2...v200 folders or other providing modules, it'll be marked as v200.3.4+incompatible, and -u will plow through every other major semver version blindly. Because it doesn't understand semver, it just has imports and can sort strings.

I mean the `+incompatible` gets added there for a reason, it's not doing it "blindly" because it "doesn't understand" it. You might not like what what go tooling does with its semver awareness, but it is semver-aware.

It's not incompatible with semver though, it's just incompatible with Go's "semver is folders".

Go's "semver" is full of weird corners. E.g. if you tag v1.2.3 and then someone does a `go get ...@master`, they get "version" `v1.2.4-timestamp-gitsha`. `v1.2.4` doesn't exist anywhere, Go just makes it up: https://golang.org/ref/mod#pseudo-versions . It works for their system with minimal changes, and is thus a clever hack, but it's definitely weird.

Reply on news.ycombinator.com