Skip to content

Revert "Add a go.mod file to make build work with go 1.16"

Daniel P. Berrangé requested to merge berrange/libvirt-go:no-mod into master

This reverts commit 90777c79.

Adding the go.mod file had unexpected consequences for consumers of the libvirt-go bindings, because in 1.16 it is not strongly enforced that libraries using modules are following semver versioning.

The libvirt-go binding has always followed libvirt native API versions 1:1 and thus uses calver, not semver. All libvirt native API versions are backwards compatible indefinitely, and the Go bindings aim to keep the same promise. With this in mind, it would be wrong to re-interpret the current libvirt-go version tags as being semver, as that will appear like an ABI break once a year when libvirt changes major version.

As a result of adding the go.mod file, consumers are unable to upgrade to libvirt-go > 7.0.0, because Go will refuse to use v7.1.0+incompatible references:

go.mod:8:2: require github.com/libvirt.org/libvirt-go: version "v7.2.0" invalid: should be v0 or v1, not v7

Effectively with modern Go, a program can only consume dependancies using calver if those deps do not provide a go.mod

Changing libvirt-go to use semver would require choosing one of the various undesirable options

  1. Delete all existing tags and go back to a v1. scheme. Trashing history is undesirable in general, and hard because Go module proxy server caches tags in a append-only, so will remember existing tags even if the repo deletes them.

  2. Rename the repo, and do (1), to get around the Go module proxy cache

  3. Pick a new major version (eg v10) and use v10. here after. Move all files under the v10/ directory and have all consumers update to the new import path. This is declaring that the new version is incompatible with all previous versions which is not actually true. This needlessly creates an interop problem until all consumers have updated.

The simplest way out of the problem in the short term at least, is to simply stop providing go.mod for libvirt-go, at which point the non-semver tags can be used by consumers as has been the case historicaly.

There's a risk that future Go releases might get even more strict and eventually break non-semver usage even in the case without go.mod, but at that time we'll be no worse off then now. So it is worth just backtracking from use of go.mod for now.

To deal with the problem 90777c79 describes, we set GO111MODULE=auto to allow non-modular builds outside of a GOPATH hierarchy.

Fixes #7 (closed) Signed-off-by: Daniel P. Berrangé berrange@redhat.com

Merge request reports