github.com/fsouza/go-dockerclient is a semantically versioned library that should be vendored by release tag instead of a random commit.
Please update vendored github.com/fsouza/go-dockerclient by tag.
Thanks.
Hi @onlyjob!
I was curious why you cared whether we used tagged release or arbitrary commits until I noticed you're also the maintainer of the nomad package in Debian! Am I right in assuming you would like to model Nomad's dependencies as Debian package dependencies which try to only package versioned releases?
Either way this is a reasonable request we'll try to address. Just wondering what the root cause is. Hopefully in a year or two vgo will make versioned releases and dependencies the norm in Go!
Yes, that's me, maintainer of Nomad in Debian.
Yes, we are packaging most dependencies as individual (reusable) packages.
This approach have significant advantages in automatic tracking of new upstream releases, CI, testing on multiple hardware architectures, security, etc. For example Golang build system run no tests for vendored libraries hence one can not be sure that dependency libraries are reliable...
Packaging libraries for reuse allows us to build confidence by testing all dependencies.
Packaging semantically versioned libraries is easier yet sometimes we have to package some commonly used libraries even if their authors don't use formal versions to tag releases...
Unfortunately Hashicorp makes it very difficult due to systematic abuse of good versioning practices. Only few Hashicorp libraries (e.g. github.com/hashicorp/raft, github.com/hashicorp/serf, github.com/hashicorp/memberlist) are semantically versioned but reghardless they are vendored in _nomad_ and _consul_ by random commits. Because of this (bad) practice _nomad_ and/or _consul_ FTBFS when built with identical versions of common libraries.
Although I've noticed fsouza/go-dockerclient vendoring inconsistency during packaging effort, I think even upstream vendoring by semantic release have advantages. For example, it is easier to track new stable releases. When vendored by commit, new commits are almost always available but you never know if it is safe to upgrade...
I do hope that _vgo_ will eventually improve versioning in Golang ecosystem. But in the meantime we can improve a lot by consistent semantic versioning whenever possible.
Thank you.
Nomad 0.8.4 is in Debian now. :)
Even in 0.10.1 this is still an issue. Currently sloppy-vendored github.com/fsouza/go-dockerclient do not match any semantically versioned releases and judging by the date of the random vendored commit, it is somewhere in between 1.3.1 and 1.3.2.
Please vendor proper release.
Most helpful comment
Nomad 0.8.4 is in Debian now. :)