go.mod: change imports to github.com/distribution/distribution/v3 #3225
Conversation
|
@manishtomar @olegburov @dmcgowan @stevvooe PTAL: adding go modules in this repository forces us to update the import paths (because this repository already has |
|
Note that the recommendation is to move all code to a |
|
|
||
| // Version indicates which version of the binary is running. This is set to | ||
| // the latest release tag by hand, always suffixed by "+unknown". During | ||
| // build, it will be replaced by the actual version. The value here will be | ||
| // used if the registry is run after a go get based install. | ||
| var Version = "v2.7.0+unknown" | ||
| var Version = "v3.0.0+unknown" |
There was a problem hiding this comment.
Just noticed this version string; updated to v3.0.0 to match the change
thaJeztah
force-pushed
the
fix_gomod
branch
3 times, most recently
from
aa3c99e
to
31b0ae6
Compare
If there's still a plan for 2.x release(s), maybe it make sense to merge this after and start |
There's release/2.x branches, so for changes to go into a 2.x release, I guess those will have to be cherry picked into those branches |
|
Rebased this one |
|
With this repository being moved to https://github.com/distribution/distribution, we should probably rename the module (and imports) accordingly, further qualifying next release to be v3.0.0 |
|
Whilst I'm waiting for the GH org invite so I can start GH review, @thaJeztah could you please change the |
|
Yup; will update the PR to use the new home 👍 |
thaJeztah
changed the title
|
Updated 👍 |
| @@ -1,4 +1,4 @@ | |||
| module github.com/docker/distribution | |||
| module github.com/distribution/distribution/v3 | |||
|
|
|||
| go 1.12 | |||
There was a problem hiding this comment.
Should we bump this to 1.13 at least? Or ideally, match it with what's in travis.yaml i.e. 1.14?
There was a problem hiding this comment.
I was considering changing it, but it's not directly related to this change. Generally I try to be a conservative to allow projects to build with other Golang versions (although Golang does not (yet) "enforce" the go version, it's possible they start doing so).
There was a problem hiding this comment.
This should probably reflect the minimum required version to build the project. I don't think we rely in any 1.13+ feature, so seems OK to keep it as-is.
There was a problem hiding this comment.
Yes; and even if building the "whole" project requires Go version X, it's possible there are consumers that only use a single package from this repo, which may in itself not require that version; we could document that the project was "tested on" / "requires" / "recommends" a specific Go version to build (e.g., in "BUILDING.md").
There was a problem hiding this comment.
👍 Sounds good. I was thinking more along the lines of "dropping the support for older versions of Go", but this is ok with me. Adding BUILD.md file with notes and instructions sounds good.
|
Can we merge it? Then the dependencies can update their source. |
I think so, it just needs a rebase. |
Go 1.13 and up enforce import paths to be versioned if a project contains a go.mod and has released v2 or up. The current v2.x branches (and releases) do not yet have a go.mod, and therefore are still allowed to be imported with a non-versioned import path (go modules add a `+incompatible` annotation in that case). However, now that this project has a `go.mod` file, incompatible import paths will not be accepted by go modules, and attempting to use code from this repository will fail. This patch uses `v3` for the import-paths (not `v2`), because changing import paths itself is a breaking change, which means that the next release should increment the "major" version to comply with SemVer (as go modules dictate). Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
|
Rebased, and did a quick find & replace to check if I missed renames from docker/distribution to distribution/distribution |
|
Hi, I wonder if there is a plan to tag a v3.x.x release? For now, if people have a dependency on this repo, would get a pseudo version like It's not a big deal, but there is quite a long time since the last release, I mean v2.7.1. |
|
We are in a process of cutting a patch release for |
|
Thanks @milosgajdos. Good to know. |
Go 1.13 and up enforce import paths to be versioned if a project
contains a go.mod.
The current v2.x branches (and releases) do not yet have a go.mod,
and therefore are still allowed to be imported with a non-versioned
import path (go modules add a
+incompatibleannotation in that case).However, now that this project has a
go.modfile, incompatibleimport paths will not be accepted by go modules, and attempting
to use code from this repository will fail.
This patch uses
v3for the import-paths (notv2), because changingimport paths itself is a breaking change, which means that the
next release should increment the "major" version to comply with
SemVer (as go modules dictate).