[alpb]

I think you either did not read the article or missed the point. Author says if you make _seemingly innocent non-breaking changes_ you might think it does not require a major version change in SemVer but in fact (for instance in case of adding struct fields) it does.

[zigzigzag]

Yes but only in Go. There are projects that have successfully evolved APIs in not only source compatible but binary compatible ways over a period of decades. Win32 and Java are the obvious candidates.

Not changing or deleting existing functions and fields is easy. The problem is that Go apparently doesn't let you reliably add things either. That is kind of a joke, how is anyone expected to be able to evolve an API if you can't even add things?

Seems like the consensus is "well it doesn't happen often so it's not an issue" which is weak. Go isn't even trying for binary compatibility, the article is only talking about source compat!

[Merovius]

> Yes but only in Go.

I don't believe this to be true. I'd say at least most languages/projects would have exactly the same kind of problems (some of them at runtime, some of them at compile time), it's just that in practice they don't really matter. So you don't know about it and it seems, to a casual observer, to work just fine.

> The problem is that Go apparently doesn't let you reliably add things either.

Neither does, at least, C. I'd guess that python also doesn't let you do it. I don't know enough about java, but I'd assume that it has the same problems.

What you need to understand is, that I applied an extremely nit-picky interpretation of stability. It's not like any of the things I mentioned are learned from experience or practical problems; I just understand the go type system enough and thought really hard whether there is an obviously correct and useful interpretation of API stability under its constraints and came up with a (mostly theoretical) result. Most projects in go that use SemVer apply a more generous and naive notion that works well enough in practice. C projects do exactly the same.

[Groxx]

doesn't that mean you thought wrong, and it is in fact a breaking, major-version change? that seems fine - it's a signal to your consumers that it may not work out-of-the-box.

[Merovius]

What I was trying to illustrate is, that the notion of versioning is broken in and off itself. By the lessons of the article, pretty much every API change is a breaking change, so you would constantly need to increment the major version, if you take SemVer seriously, meaning minor versions don't exist, de facto. And if you now imagine that you'd need to touch your code every time one of your dependencies increments their minor version (I mean. Likely you can't, because you have no notion of how often that happens, because currently all your tools just ignore those changes), lest people can't build your software because the packaging tool needs to assume an incompatibility that needs manual resolving, you will see how useless this makes versioning.

Now, there are two ways out of this mess: One is to ignore it and just assume that, in practice, some things will are more likely to break consumers than others and just apply a reasonable case-by-case judgement. It's what's happening right now in probably ~every language for ~every tool out there. I think it's reasonable, but I personally dislike it, because for one, humans eff up all the time, so relying on them having a good notion of what breaks and applying it consistently and timely leads to pain. This whole article is born out of the idea, that these things should be codified and then automatically applied, I shouldn't even have to need to know what version my package currently is, IMHO.

The other way out is much more complicated: Transition to a notion of breakage not by versioning APIs, but by defining it in terms of pairs of packages. This also has a bunch of definite and obvious deficiencies (for example that you don't have access to all the code that imports you. Or the combinatoric explosion).

Currently, my personal hope is that this can be solved by supporting gradual code repair (see, e.g. https://github.com/golang/go/issues/18130 for what this means and how this is currently progressing) and then add good tooling (I'm working on something, but I have limited time and brain space). We'll see :)

[Groxx]

A good chunk of that is that Go, by design, makes nearly all changes breaking (as you covered pretty well). I doubt they did so intentionally, but they seem to focus their decisions on small-ish scale projects at the expense of large / longer-term ones, and this is the natural consequence.

I think the focus here makes sense, and improves lots of useful things in practice (which is why they do it - Go focuses on pragmatism), I just don't really like it. Every non-side-project I've worked on has chafed under weaknesses that Go seems to embrace, because the code has had to survive and grow for a couple years. It's a sizable step up from Python tho.

As far as ways out of this mess... not sure. A lot of the problems are solved by "hit it until it compiles", which is a good thing, and often implies automated code-rewriting tools are possible. The rest (adding methods -> you may collide with an interface which you didn't before) can probably be detected so you at least have your potential-problems enumerated. There are some fairly sophisticated tools out there for doing both of these, e.g. https://github.com/facebook/codemod , and it'd be great to see more language-communities embrace (and improve) them IMO.

If you manage to limit most of your changes to "can be automatically changed / detected", you have a fair bit more freedom. With Go's limitations... maybe enough? I'd have to read and think a lot harder to figure out if there would be too many things that fall into those gaps.

[Merovius]

> they seem to focus their decisions on small-ish scale projects at the expense of large / longer-term ones, and this is the natural consequence.

This is - excuse me - a pretty ridiculous claim, given the explicit design goals of go. https://talks.golang.org/2012/splash.article You might disagree, that their choices are furthering these design goals (I don't), but claiming that they focus on small-ish projects is just non-factual, most design decisions are driven by a focus on large (both in problem- and code size) projects.

> A lot of the problems are solved by "hit it until it compiles"

Neither do I want to need to fix compilation errors in software that I use, nor do I want my users to have to do it. This is not a solution to the problems at hand.

> The rest (adding methods -> you may collide with an interface which you didn't before) can probably be detected

No, they can't. From looking at your code you only get an outwards pointing import-arrow. There is no way for you to know which code actually relies on your API and in what way. You might, say, limit your guarantees to packages on godoc.org (which is indeed what I do in practice), but it's still hardly a solution to the problem.

> If you manage to limit most of your changes to "can be automatically changed / detected", you have a fair bit more freedom.

This is indeed the path I'm currently following; for every breaking change, provide an automatic fix. It still isn't an actual solution, though, just a halfway decent workaround. It especially doesn't work without https://github.com/golang/go/issues/18130 and a couple of other needed changes.

Luckily, go has immensely powerful tools to perform these kinds of rewrites (much more powerful than any other language I'm aware of) and I'm thus pretty optimistic that this will provide a good way forward soon (now that the need for gradual repair is officially recognized).

[Groxx]

Yeah... no, they're not focusing on large. Look at the vendoring hell, the weak typing / nonsense around no-generics vs oh-but-maps-are leading to error-prone switch statements, and lack of control-of-the-language. Larger than Python projects tend to support without pain, absolutely (and that's an important area), but not large. Service-units in a large system, sure, which is likely what many will use it for, but it's just not friendly to millions of lines of code and tens or hundreds of developers. Their solution to things getting out of hand or having performance problems is to divide the system, not to have a system that can handle it.

edit: oh boy, right at the top, a winner: Go's design considerations include rigorous dependency management, ...

Heck no it doesn't. It has been hacked on by the community, which has thankfully adopted things like Glide and GPS that do things properly, because it abandoned this whole area. As it did with e.g. debugging, for which their official stance is "use GDB, which doesn't really work".

[Merovius]

> the weak typing

What do you mean?

> nonsense around no-generics

What nonsense?

> error-prone switch statements

What makes them error-prone?

> lack of control-of-the-language

What do you mean?

> not large. Service-units in a large system, sure, which is likely what many will use it for, but it's just not friendly to millions of lines of code and tens or hundreds of developers.

There are go-projects like this on github. Not to mention the fact that several large companies run central parts of their infrastructure on go (I recently started working on a go-project that qualifies). I think your belief that the flaws of go disqualify it for large projects is biased on a certain, subjective perception to do things, not the objective absolute truth you are trying to make it out to be.

But even if it was correct, at best you are arguing that their efforts to focus on large software was in vain, but claiming that they don't focus on large software at all is, again, simply completely false. Please try to be constructive, here.

> Their solution to things getting out of hand or having performance problems is to divide the system, not to have a system that can handle it.

Can you give an example?

> As it did with e.g. debugging, for which their official stance is "use GDB, which doesn't really work".

I don't believe that's the official stance anymore. And IMHO, most large applications don't particularly profit from an interactive debugger anyhow (I can't just attach a debugger to a server serving thousands of requests per second and have any hope of getting useful answers). The debugging story of go is much more bound to things like "import _ net/http/pprof" and the like and systems like stackdriver.

Anyway. All of this is pretty off-topic, anyway.