I am replying mostly to https://resea rch.swtch.com/vgo-import article.
It is proposed that "moauth" author should do double work, even if his code works absolutely fine with either verion of oauth. This viral effect will be causing chain reaction and a lot of people will be creating unnecessary major semver releases. "moauth" author doesn't need to do anything, but once vgo is out , he'll be receiving requests from "aws" to do theese releases and "aws" itself will be blocked on somebody else without a way to move forward with "oauth/v2". It will also cause combinatorial explosion, just imagine if "moauth" depends on "oauth" and "samlauth", would it need to release 4 major semver versions for all combinations of dependencies visible in API? Looks like it is inevitable, as users of "moauth" can decide to use types from either version of "oauth" and "samlauth". IMHO right solution vgo should promote is to apply semver trick described here: https://github.com/dtolnay/semver-trick/blob/master/README.md . In a nutshell it suggests that "oauth/v1" imports "oauth/v2" and type aliases all common types visible in API. Then "moauth" doesn't need a new semver release at all, it stops being viral and whole dependency chain becomes much much simpler. Go community is going to to do pretty much whatever Russ tells them with imminent vgo release, if smever trick indeed solves this viral problem, it should be encouraged from day 0. -- 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.
