following on up on this. Is there anything that would help make my case? is this a case of "the ship has already sailed", nobody wants to take the time to maintain tags in the future, etc? we could potentially fork stuff internally and add tags ourselves, but that comes with all of the obvious problems and probably lots of non-obvious ones as well.
On Tue, Sep 19, 2017 at 8:46 PM, Peter Moody <pmo...@uber.com> wrote: > On Tue, Sep 19, 2017 at 5:42 PM, Ian Lance Taylor <i...@golang.org> wrote: >> On Tue, Sep 19, 2017 at 9:36 AM, 'Peter Moody' via golang-nuts >> <golang-nuts@googlegroups.com> wrote: >>> >>> We're big consumers of the x/crypto packages, but the lack of semantic >>> versioning tags means that our dependency management tools can easily >>> pull in incompatible versions when we update. >>> >>> what would it take to start tagging releases of x/crypto? >> >> How do these problems show up? > > by way of example: > > library L1 depends on x/crypto/ssh post 527d12e (introduction of the > IsHostAuthority) > library L2 depends on x/crypto/ssh, no version tag > service S depends on L1 and L2 > > we use glide, and depending on the ordering of how glide determines > dependent versions (and what may or may not be in a local cache), the > version of x/crypto that's included the final glide.lock may or may > not have contain a version of the ssh library has IsHostAuthority. > > Now, we can pin L1 to master, but there aren't any api compatibility > guarantees when one is pinned to master. Alternatively, we can pin L1 > to 527d12e, but we're in a bad spot if L2 depends on a feature that's > introduced after 527d12e > >> How would the problems be fixed by adding semantic versioning? > > assuming x/crypto at the IsHostAuthority change is tagged at 1.0 and > the new feature needed by L2 is pinned at something later, adding > semantic versioning to x/crypto allows us to do something like > > pin L1 to ^1 > pin L2 to ~1.1 > > now glide can know that anything that satisfies L2 will satisfy L1. > > there are obviously corner cases where you can make the semantic > versioning barf (someone needs to do work if L2 wants to pin to ^2 for > instance, but a major version bump implies an incompatible api change > so that should be somewhat expected) but this at least allows services > and libraries to reason about the stability of an api at a version. > > Cheers, > peter > >> (I'm not opposed to semantic versioning but I don't really understand >> how it would help here.) >> >> Ian -- 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.
