Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update "github.com/fsouza/go-dockerclient" #4428

Closed
onlyjob opened this issue Jun 20, 2018 · 6 comments
Closed

Update "github.com/fsouza/go-dockerclient" #4428

onlyjob opened this issue Jun 20, 2018 · 6 comments

Comments

@onlyjob
Copy link
Contributor

onlyjob commented Jun 20, 2018

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.

@schmichael
Copy link
Member

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!

@onlyjob
Copy link
Contributor Author

onlyjob commented Jun 25, 2018

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.

@onlyjob
Copy link
Contributor Author

onlyjob commented Jun 28, 2018

Nomad 0.8.4 is in Debian now. :)

@onlyjob
Copy link
Contributor Author

onlyjob commented Nov 7, 2019

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.

@nickethier nickethier added this to the 0.11.0 milestone Dec 5, 2019
@tgross
Copy link
Member

tgross commented Apr 6, 2020

Closed by #7550

@tgross tgross closed this as completed Apr 6, 2020
@github-actions
Copy link

github-actions bot commented Nov 9, 2022

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants