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.
