Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backwards compatibility in Go (2015)

blog.merovius.de

Post reply on HN
Print view View original

11–20 of 36 posts

Re: Backwards compatibility in Go (2015)

#11

Post by Groxx »

alpb wrote: post #6
bottled_poe wrote: post #4

Earlier quoted context omitted.

There's no need to reinvent the wheel. Semantic versioning already defines a standard for managing version changes in a pragmatic way. http://semver.org/

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.

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.

Re: Backwards compatibility in Go (2015)

#12

Post by Groxx »

Well yeah, much of this is true for many languages / libraries. And some of the more annoying ones that other languages don't tend to suffer from (adding a method) are largely due to Go's duck-typed interfaces, or the lack of constructors (there's no way to have optional values, except via factory methods. you could use nothing but factory methods, but it simplifies initializers so much you are disincentivized to do so).

Re: Backwards compatibility in Go (2015)

#14

Post by 0xCMP »

I think what the author was trying to figure out was not just when you should do a major/minor version update, but how that could be done automatically. An example is how in Elm it can detect a major vs minor change and bump your numbers automatically when you publish. Something like that for Go could be built into some tool to help package maintainers (public + private) keep SemVar up to date automatically since there are already types and there are ways to possibly detect changes since a previous version.

I imagine you could write a tool that would check the previous highest "v*" tag in git's version of the project vs now using something like go-guru and determine if any public interfaces were changed and that could automatically determine if it's a major or minor bump.

Re: Backwards compatibility in Go (2015)

#15

Post by throwaw180ay »

> tl;dr: There are next to no "backwards compatible API changes" in go. You should explicitely name your compatibility-guarantees.

It's not a problem in languages that come with a package manager, or at least promote a specific one to handle dependencies.

It's only a problem in languages where developers thinks "you don't need that". There is this weird belief in the Go community that Go is a miraculous language where good programming practices don't apply because Go magically make them irrelevant. It also stems from the Go team itself, which used to claim that "at Google, we don't need this or that" and then the Go community spreading the "gospel" : "Go doesn't suit you because it wasn't created for you"(?!?).

Hopefully Russ Cox sees that light, he even wrote a paper about "Go zealots" ( https://news.ycombinator.com/item?id=13356531 ) and how they refuse any change in the language, even when "teams at Google needs it". The irony

Re: Backwards compatibility in Go (2015)

#19

Post by Merovius »

twotwotwo wrote: post #8
xja wrote: post #2

The author is essentially saying any API change has the potential to break backward compatibility and that we should define what kind of breakage is ok. That's kind of interesting, and I'd not considered many of the scenarios mentioned (which apply beyond go). Perhaps the "correct", but cumbersome thing to do is supply different versions of the API when maintaining backward compatibility and never change the old vers…

Most of these are treated as backwards incompatibilities by the stdlib folks and most users. The one that's not is that adding a field or method could break importing code. The scenario here is that you embed two types, one from the upgrading lib and one not, and the upgrading lib adds a name that collides with one in the other type. Rather than pick a winner in that conflict (last embed in the type definition wins,…

> The practical backwards compatibility things that I have seen come up

Yes, I'm not really talking about practical problems :) This article is mainly a response to various people claiming, "backwards compatibility is easy, it's a breakage if you are breaking the build".

FWIW, most of the scenarios you mention I wouldn't really call a backwards compatibility issue either, though. I'd say they are bugs that are exposed by a change in API.

Re: Backwards compatibility in Go (2015)

#20

Post by Merovius »

alpb wrote: post #18

After I posted this I thought of writing a tool that checks if you are making breaking API changes in your go package. Turns out there is already one: https://github.com/bradleyfalzon/apicompat/

The article was created because I was starting to write a tool to do this. After sitting down and thinking about it quickly, I came to the conclusion in the article: There is no non-breaking change (or rather: That determination can not be made from the package you are looking at). At that point I put the idea to rest :)
Post reply on HN