> > Yes, definitely. The only way that *wouldn't* break a reverse dependencies > code is if they'd only use the function with number-literals. Which is > sufficiently unusual to be put very firmly on the "breaking change" side of > things. >
And even then it technically breaks, because range of possible values changes. Side question, would hyptohetical future generics substantially reduce number of API breaking changes? > > FWIW, I've written > <https://blog.merovius.de/2015/07/29/backwards-compatibility-in-go.html> > about backwards compatible API changes of Go code in the past; the gist is > "if you're sufficiently nitpicky, no API change is ever non-breaking". I > don't think this is a practical viewpoint. > Great writeup! Even if it is not practical viewpoint, it is reality. It is made worse, by each maintainer having different view on what "API compatibility" means. In current world, version locking somewhat sweeps this problem under the rug, but in vgo it would be much more visible. As you said in he link, we (go users) would need official set of rules, stating what it means to be API compatible. > But I also don't see how this question can *at all* be answered in a > pragmatic and correct way. Even if we'd agree that certain changes are okay > and others aren't, that will necessarily put restrictions on how we can or > can't use the language in an intolerable way. For example, any definition > of "breaking change" should probably exclude adding fields to a struct, but > the only way to guarantee that you are not broken by an added field is to > never embed structs, which, of course, isn't really sensible either. > > IMHO any official definition of breaking change is better than no definition even if it means that always working builds goal (which is kinda idealistic already, but it is good to try to achieve it) of vgo is not going to happen in some edge cases. Official guidelines would allow linters to emerge, and these tools will be advising developers, that they are breaking things and should either cut a new major release or think again. > So, in the end, what it boils down to (IMHO) is: Go by your gut and > accept, that you'll be wrong every once in a while. Semantic versions are > not a technically enforced contract, but just a handwavy human promise. As > a maintainer, be conscious of what kinds of usages you do and do not care > about to break and as a user test your stuff and check that your build > still works with pre-release versions every once in a while. > Gut feeling works, until official packaging system starts to rely on human decisions :) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
