Backwards compatibility in Go (2015)
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.<p>That&#x27;s kind of interesting, and I&#x27;d not considered many of the scenarios mentioned (which apply beyond go).<p>Perhaps the &quot;correct&quot;, but cumbersome thing to do is supply different versions of the API when maintaining backward compatibility and never change the old version.