Not planned
Description
Hey Folks,
I couldn't find this discussed elsewhere, so I'm asking here: Would it be possible to create a new release (and hopefully restart the process of creating regular new releases)?
Background: Apparently there hasn't been a new release since June 2017 (v17.03.2-ce). I wouldn't really care about this, except that the Go language is moving to adopt modules (i.e. versioned releases of packages), and go uses the latest github release as the default version of a module to fetch. So by not updating releases here (AFAICT), it makes it confusing (though not impossible) to use Go modules with moby.
More background/repro is in this golang issue I filed.
Activity
faraazahmad commentedon Apr 15, 2019
would this be related to why i am unable to
get get github.com/docker/docker/client?cpuguy83 commentedon Apr 15, 2019
Releases are handled through github.com/docker/engine currently.
You should target the branch/tag for the release you are wanting to support.
The other part of this is Docker does not follow semver, and while generally we do try to not break the package level API's it does happen from time to time.
This does not follow with the go modules method of versioning and will require manual management.
faraazahmad commentedon Apr 16, 2019
So should I
go get github.com/docker/engine?monkeyWie commentedon Jul 22, 2019
Hey, do we have a solution now?
ldez commentedon Aug 4, 2019
As the go modules will become the default/standard for Go projects, is it Docker/Moby will reevaluate its versioning policy?
cpuguy83 commentedon Aug 4, 2019
Changing the versioning will not fix any problems caused by modules.
The fact that there are non-semver versions alone breaks automatic version selection.
That plus the fact that semver just does not make sense for the engine.
Having a library in a client lib in a separate repo which is semver kind of makes sense, but is hugely difficult to maintain.
For those wondering if there is a solution, yes! Use a "replace" directive and specify the docker/engine repo and tag that you want.
ldez commentedon Aug 4, 2019
the "replace" directive is not transitive (if a project depends of a lib that specify the replace directive, the replace will not apply to the project), so it's an unstable solution.
But I understand your point.
ldez commentedon Aug 4, 2019
Sorry to bother you, are you planning to replace the
vendor.conffile withgo.mod?Even if you do not use semver.
cpuguy83 commentedon Feb 7, 2020
On the maintainers call today we discussed making client a dedicated module with its own tags (ie client/ will get its own go.mod and special tags client/) which, in theory, should work with go get.
28 remaining items