Please see: * https://github.com/golang/go/issues/26420 * https://godoc.org/golang.org/x/exp/cmd/apidiff which uses https://godoc.org/golang.org/x/exp/apidiff
Effectively what you are discussing is broadly covered, at least based on current thinking, in the go release command. On Wed, 19 Dec 2018 at 18:51, Geovani de Souza <geovanisouz...@gmail.com> wrote: > > First, let me say that the current implementation of Go Modules is awesome > and solves most of the problems I've faced until now. > > In the spirit of embracing good packages and stability for consumers, I think > that the current tooling should detect breaking changes and enforce (or at > least, recommend) upgrade in the semver of those packages. > > By breaking change, I mean: > > - If we add a new type or func on an existing type (a new feature), it's not > considered a breaking change; > - If we change the signature of an existing method or remove some type/func, > it's considered a breaking change; > > Of course, we can break existing packages by changing it's implementation, > but I'm talking about public API, only. > > I'm not sure how to implement this, but I find this paper > (https://homepages.dcc.ufmg.br/~mtov/pub/2018-saner-apidiff.pdf) and > recommend looking forward how Elm achieve that. > > --- > > What do you think about it? > > -- > 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. -- 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.
