Need a release so default golang tooling will work

[tych0]

Right now we get failing builds: https://travis-ci.org/github/anuvu/stacker/jobs/699350166

And when I replace things globally, I get:

go build -tags "exclude_graphdriver_devicemapper containers_image_openpgp" -ldflags "-X main.version=v0.5.0-145-g0f7558c-dirty" -o stacker ./cmd
go: github.com/opencontainers/umoci@v0.4.6-0.20200326170452-7654d6c16c17: parsing go.mod:
	module declares its path as: github.com/openSUSE/umoci
	        but was required as: github.com/opencontainers/umoci
make: *** [Makefile:11: stacker] Error 1

I can use replace to work around this for now, but we should probably do a release to fix this behavior.

[cyphar]

I want to get #324 fixed for a variety of different reasons (it's only blocked because it turns out that Go's archive/tar has regressed, and umoci's CI has been testing on Go 1.11 for a long time because of a bug in openSUSE's go package). We can do a release immediately afterwards.

[cyphar]

I think the issue is not a matter of having or not having a release, but instead that existing projects which use github.com/openSUSE/umoci as an import path will end up seeing a module which has the wrong name resulting in compilation errors. This is quite bad, and I didn't realise this would happen (this is caused by Go modules -- in the pre-Go-module world this would've "just worked"). This means we'll need to have some kind of migration setup to avoid this issue. The simplest solution would be to just keep our old name but that seems like a bad idea.

Instead, what I propose we do is make a copy of the umoci package at 2bd0ec2 in the @openSUSE project. This would break the redirect permanently, but then I will add the following line to all of the packages in the mirror project:

//#warning This module has been moved to <github.com/opencontainers/umoci>. \
//         Please update your import paths, as <github.com/openSUSE/umoci> will \
//         not receive any further updates.
import "C"

As well as a note in the README explaining the situation, and archive the entire project. Annoyingly this is the only way to insert build warnings into Go programs, but it should hopefully work everywhere.

However if we're going to go through all of this pain anyway, maybe we should consider using vanity imports (umo.ci/cmd/umoci or something). This is fairly easy to do, we just need to add the following lines to our umo.ci homepage:

<meta name="go-import" content="umo.ci git github.com/opencontainers/umoci">
<meta name="go-source" content="umo.ci https://github.com/opencontainers/umoci https://github.com/opencontainers/umoci/tree/master{/dir} https://github.com/opencontainers/umoci/blob/master{/dir}/{file}#L{line}">

But I'd like to know what you both (@tych0 and @vbatts) think about vanity URLs or if we should just use github.com/opencontainers/umoci.

[tych0]

existing projects which use github.com/openSUSE/umoci as an import path will end up seeing a module which has the wrong name resulting in compilation errors.

Exactly. I don't think this a particularly big deal, since as far as I'm aware, there is only one downstream project, and I already fixed it :). I'd say save yourself the pain and just tag a new release.

[cyphar]

We can tag a new release, but if people are going to get compilation errors anyway we might as well make them explain what they should do.

[cyphar]

I've set up https://github.com/openSUSE/umoci to have a dummy release of v0.4.5.1 which just gives you compilation warnings. This will stop users from getting compilation errors but will tell them to switch their import paths over. I will prepare a new release of umoci soon (it'd be nice to merge #318 first though).