[grey-area]

You are arguing for versionless libraries? AFAIK the go maintainers tried that with golang itself in the beginning, and gave up on it, because it's not practical in real world use when APIs are changing quickly and outsiders want to know if they can update without breaking. There are very few libraries which have managed this in the past and have remained at version 1.x for their lifetime.

It's interesting that go get supports reading version tags, though it's a bit pointless to support them for language changes, since go1 is stable, go2 is unlikely to arrive for years, and Gofix would be best used to fix any issues with a major transition like that anyway. So in practice this feature is not used.

It'd be nice if go get instead supported reading version tags for packages, and had some simple scheme for getting the latest compatible version using semver and versioning import dirs, rather than simply pulling the latest master. I think to do that they'd have to adjust go get and go build/run though, perhaps to add a lock file and to take dirs like github.com/foo/bar-v1.2 into account. Simple versioning would not be a difficult change or an incompatible one, it just wouldn't deal with the very difficult issues of conflict resolution on larger projects, which I think was the golang team's objection (correct me if I'm wrong). I do see why they don't want to introduce a half-baked solution without dependency resolution.

At present either library authors are expected to never break compatibility ever (your proposed solution), or everyone has to update their code when they do. This particular detail seems like undesirable behaviour or an unresolved problem in golang to me, rather than a carefully thought out convention. Just because that's the way it is doesn't mean that's the way it should be.

[jzelinskie]

I don't think they've given up on the idea considering there still is no official version management. To give up would mean that they're doing something else and AFAIK this is still best practice. The early Go team did believe this would be an okay idea, but over time everyone has noticed that it may not be for the best. However, the Go team also punted on solving the problem while thinking that the community will figure something out. The problem is that "go get" is already built into our standard toolchain. The moment you start using a dependency manager, now the official toolchain workflow is broken and you've fragmented the ecosystem. If people really want a solution to this problem they need to prod the Go team and finally get an official decision made and merged into the go tool, rather than just creating their own binary.

[grey-area]

I don't think they've given up on the idea considering there still is no official version management.

Sorry, that wasn't clear, I was talking about the language itself - the language is now versioned, but it wasn't for initial releases - they had weekly snapshots, then moved to formal versioning and gave up on the idea of being version-less. See these slides about version 1:

http://talks.golang.org/2012/go1.slide

What holds for the language holds also for libraries I think - having explicit versioned releases and being able to sometimes break backwards compatibility is really useful, esp. if others can pin whatever version they import easily and migrate at their own pace.

I think it's good people are experimenting with pkg versioning - if someone comes up with an elegant solution and deals with most of the edge cases, it'll probably get into the bundled tools like go get eventually, or people will stop using go get and use another better tool. go get is not essential for fetching go libraries, it's just the blessed method.

[nevir]

I suspect it stems more from the Google origins than anything else.

Most of Google's code base is one big repository, and everyone is working at HEAD. It's nice not having to support a matrix of dependency versions, but that really only works when you can also modify downstream dependencies with ease.

That works within Google because there's a culture of constant maintenance; but out in the real world, you can't expect OSS package maintainers to be constantly active & willing to accept patches.

[grey-area]

Yes, you're probably right, it does sound like they work this way internally, but it's not really practical if you have an open ecosystem with lots of different packages by authors who are not paid to maintain them. It'll be interesting to see if they bend on this and adopt some versioned solution.