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>
Now that we've tagged a release candidate, we can now say all builds are
"2.4.0+unknown" if the makefile is not used.
Signed-off-by: Richard Scothern <richard.scothern@docker.com>
Now that we've tagged a release candidate, we can now say all builds are
"2.1.0+unknown" if the makefile is not used.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
We've added support to the registry command to report the current version of
the distribution package. The version package is generated with a shell script
that gets the latest tag and add "+unknown". This allows builds from "go get"
and "go install" to have a rough version number. Generated periodically, it
will provide a decent indication of what code built the binary. For more
accurate versioning, one can build with the "binaries" make target. Linker
flags are used to replace the version string with the actual current tag at
build time.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
