Backwards compatibility in Go (2015)
blog.merovius.de
Backwards compatibility in Go (2015)
1–10 of 36 posts
Re: Backwards compatibility in Go (2015)
#2The 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 version.
Re: Backwards compatibility in Go (2015)
#3The 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…
Then what's the purpose of the promise in the first place? That's just having the old APIs and compilers with the new optimisations (at least what I understood from your suggestion).
Re: Backwards compatibility in Go (2015)
#4The 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…
There's no need to reinvent the wheel. Semantic versioning already defines a standard for managing version changes in a pragmatic way.
Re: Backwards compatibility in Go (2015)
#5This reminded me of "Spec-ulation" from Rich Hickey [0]
Re: Backwards compatibility in Go (2015)
#6The 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…
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.
Re: Backwards compatibility in Go (2015)
#7The 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…
The main point of the article to me is "adding fields to Go structs is a breaking change" since your users could be using implicit struct initializer syntax, which will cause a compilation error. They have listed other points too, but I think this one can be highlighted.
Re: Backwards compatibility in Go (2015)
#8The 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, say), Go raises an error so the human can explicitly resolve it by, e.g. renaming one of the conflicting names if you control the code (gorename helps!) or changing one of the embeds to a regular member.
This can happen, but I haven't seen it occur in the time I've been around the Go community, and never adding methods doesn't make sense, and silently resolving those conflicts could _still_ cause a backcompat issue and seems worse than the status quo, and if you do hit the conflict it's often resolvable (gorename!), so I think calling it backwards compatible to add a method/field is reasonable (as well as what everyone already does).
The practical backwards compatibility things that I have seen come up tend to have less to do with folks hitting cases like that than changes that are theoretically right but expose code that was buggy but happened to work before, e.g. programs that used to rely on racy map accesses or wrong cgo pointer usage or invalid Less functions in sort working, or trickiness around net protocol interfaces and buggy clients, or parallel tests exposing something.
Re: Backwards compatibility in Go (2015)
#9The 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…
The main point of the article to me is "adding fields to Go structs is a breaking change" since your users could be using implicit struct initializer syntax, which will cause a compilation error. They have listed other points too, but I think this one can be highlighted.
Using the unkeyed initializer syntax is discouraged anyhow: https://golang.org/cmd/vet/#hdr-Unkeyed_composite_literals
Unkeyed syntax also doesn't work for a struct in another package with at least one private field.
One common exception is a vector type that isn't expected to change--RGBA, XYZ, LatLon, etc.
Re: Backwards compatibility in Go (2015)
#10The 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…
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/
If you follow semver, this article tells you when you need to bump the major version versus the minor. The gist is the article is that you almost always need to bump the major version.