On Thu, Sep 28, 2017 at 1:23 PM, Ian Lance Taylor <i...@golang.org> wrote: > On Thu, Sep 28, 2017 at 1:12 PM, Peter Moody <pmo...@uber.com> wrote: >> 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. > > As you suggest, I don't know that anyone is going to volunteer to take > the time to maintain semantic versioning tags for this repo. If there > is a way that the tags can be contributed using the usual contribution > process, and if there is some documented set of guidelines for when > the tag should change, then perhaps we could handle it that way. If > we have to rely on a specific maintainer doing it, then I don't know > who that would be.
there are guidelines for semantic versioning, and when major, minor or patch level versions should change (and what customers can expect from those changes). Would you be amenable to to CL's that just add tags (can go.googlesource.com handle CLs like that?) if I'm the only person in the greater go ecosystem who cares about semvers on x/crypto then it's probably not worth the time because I don't check back in often enough to reliably know when tags should be cut. > Ian > > > > >> 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.
