I disagree that it's solved. 90% of community libraries aren't even following the gp's recommendation, let alone minor and incremental release versions. And as you said, there's no standard. With nexus/maven repos, when you push v1.4.2 of your library, that's it, it's only published once and everyone sees the same thing. Bug fixes can go out in 1.4.3, new features in 1.5.x and incompatible features in 2.x. Right now, even if everyone followed GP'S advice, I still risk a bug fix breaking my code, or different behavior depending on when I last ran go get.
There is no official stance on package versions, because the core Go development doesn't really need/use it.
The Go 1 compatibility guarantees no backwards incompat changes to stdlib. Experimental package development occurs at golang.org/x/foo ("x" for experimental, presumably). Those packages are unstable, and there are no versions. If they change at all you have to update.
People follow the 'official' approach blindly, but aren't experienced enough to know what the tradeoff's in the official approach are.
I don't understand how any software can possibly enforce semantic versioning. Sure, you can ensure that 1.4.2 is immutable, but you can't enforce that breaking changes aren't put in 1.4.3.
As I said, there are tools that let you freeze the exact commit number your code depends on, which effectively gives you frozen minor version numbers if you want it. And of course you can also copy the code into your repo with godep, and not need any external services outside your own VCS.
> you can't enforce that breaking changes aren't put in 1.4.3
Eh ... why? In some languages, it's standard to run source/binary compatibility checks against new versions and fail a build if the new version doesn't satisfy the requirements.
With decent static analysis you could check that the signatures of all types and functions are identical or compatible, I suppose, but checking that the functionality is compatible in any kind of generic way is impossible. The former is necessary, but not sufficient.
> With decent static analysis you could check that the signatures of all types and functions are identical or compatible, I suppose
"I suppose"? This has been done for years already. There are even GUIs for that (so that people don't have to use the CLI) which tell you "between 1.2.3 and 1.2.4 you did the following: ... This will break compatibility in the following cases: ..."
So it's better to not even try?
Additionally, for many changes it is reasonable and possible to check whether behavior has changed. Not every function has an unlimited number of inputs and outputs.
That's one of the biggest reasons I avoid Go and PHP: It's not only that the developers ignore existing solutions if they haven't "invented" them themselves, but that they don't even care about improving things where no "perfect" solution is available.
Ignorance and arrogance is a combination which doesn't make me trust them, and products based on their software. (OwnCloud, Docker, ...)
I'm not saying "don't write a tool that does this". Sure, having an API diff tool for my code would be awesome. And it's possible someone has already written such a thing for Go. If not, someone definitely should.
The problem I have is when other developers say "How can anyone possibly live without this?!" People have been living without X or Y feature some other language / toolchain has for a long time, and doing pretty ok. That doesn't mean we don't want that feature, just that we don't think it's the end of the world if we don't have it. Everyone seems to have their own pet "I can't live without this" thing. The thing is, when you've been coding for a long time, you start to realize that you can live without pretty much any feature. It may make some parts of your job harder, but unless we're talking about dropping down to assembly, I can deal with pretty much any language.
Well, let's just agree that there is some kind of selection bias in the Go community.
Go developers seem to be emphatically content with not using the best tool for the job. That makes sense, otherwise those developers wouldn't have ended up with Go in the first place.
For me it's not a question about "I can live without X?", but "why would I want to live without X?". I want the best tools to solve a job. Not some of the best tools. _All_ of them.
I'm gonna just throw it out there for you: You Do Not Get It when it comes to Go. Internalize that. Nobody, fucking nobody ever, has said "this tool sucks, I think I'll use it exclusively from now on".
They're seeing something that you are not seeing, most likely an appreciation of simplicity.
You read the golang mailing list? In addition to showing up on every HN and probably proggit thread about Go? How much time have you spent actually programming?
