Version tags don't all work with Go modules

Question

Version tags don't all work with Go modules

QuLogic opened this issue 5 years ago · comments

Elliott Sales de Andrade commented 5 years ago

In an empty package, trying to load govcr with Go modules grabs some older versions:

$ cat go.mod 
module example

go 1.12

$ go get gopkg.in/seborama/govcr.v2
$ go get gopkg.in/seborama/govcr.v3
$ go get gopkg.in/seborama/govcr.v4
go: finding gopkg.in/seborama/govcr.v4 latest

$ cat go.mod 
module example

go 1.12

require (
	gopkg.in/seborama/govcr.v2 v2.2.1 // indirect
	gopkg.in/seborama/govcr.v3 v3.0.1 // indirect
	gopkg.in/seborama/govcr.v4 v4.0.0-20190303132007-6b478b087ffb // indirect
)

The latest v2 tag seems to be 2.4.2, but it doesn't get found because it's missing the v prefix (note: it's also missing from gopkg.in.) The latest v3 tag is v3.2 and the latest v4 tag is v4.4. However, modules seem to require semver which needs 3-component versions, i.e., quoting from the Modules wiki page:

Modules must be semantically versioned according to semver, usually in the form v(major).(minor).(patch), such as v0.1.0, v1.2.3, or v1.5.0-rc.1. The leading v is required. If using Git, tag released commits with their versions. Public and private module repositories and proxies are becoming available (see FAQ below).

So if these were re-tagged with a trailing .0 (e.g., v4.4.0), I think this would work (though I'm not totally sure, Go modules are fancy new things.)

Seb C · Answer 1 · Mon Jul 22 2019 05:53:33 GMT+0800 (China Standard Time)

Hi @QuLogic ,
Thanks for raising this. I've updated the releases (kinda painful lol).
Bonne chance,
Seb

Elliott Sales de Andrade · Answer 2 · Thu Jul 25 2019 11:56:53 GMT+0800 (China Standard Time)

Thanks, but it seems like all of the tags point to the exact same commit, which seems wrong?

Elliott Sales de Andrade · Answer 3 · Thu Jul 25 2019 12:02:48 GMT+0800 (China Standard Time)

It looks like you might have deleted the old tags, but fear not, one of these forks should have the original tag-commit mapping:

https://github.com/csonya/govcr/releases (except maybe 4.5; that doesn't exist, right?)
https://github.com/michaelw/govcr/releases
https://github.com/TheMushrr00m/govcr/releases

Seb C · Answer 4 · Thu Jul 25 2019 18:45:47 GMT+0800 (China Standard Time)

Oh no... I renamed the release versions so I'm not sure how that happened :/

Seb C · Answer 5 · Thu Jul 25 2019 23:49:22 GMT+0800 (China Standard Time)

OK, I'm in the process of restoring the tags and renaming as per go mod standard.
I've processed v1.0.0 and v1.1.0 so far and it seems to be correct.
Let me know how those 2 look from your perspective.

Elliott Sales de Andrade · Answer 6 · Fri Jul 26 2019 04:29:35 GMT+0800 (China Standard Time)

Those appear to be consistent so far, yes.

Seb C · Answer 7 · Fri Jul 26 2019 05:34:35 GMT+0800 (China Standard Time)

OK, I'll carry on.

For what it's worth:

#!/bin/bash

OLD_TAG=$1
NEW_TAG=$2

if [ $# -ne 2 ]; then
    echo "Usage: gitRetag.sh old_tag new_tag"
    exit 100
fi

if [ "${OLD_TAG}" == "${NEW_TAG}" ]; then
    echo "'old_tag' and 'new_tag' must be different"
    exit 100
fi

COMMIT=$(git show "${OLD_TAG}" | awk '/commit/ { printf $2 }')
if [ -z "${COMMIT}" ]; then
    echo "Could not resolve the tag to a commit"
    exit 100
fi
echo "Commit: ${COMMIT}"

echo "About to re-tag ${OLD_TAG} to ${NEW_TAG}"
read -p "Confirm [yes/-]: " ANS
if [ "${ANS}" != "yes" ]; then
    echo "Aborting"
    exit 100
fi

git tag -d ${OLD_TAG}
git tag ${NEW_TAG} ${COMMIT}
git push --tags --force
git push origin :refs/tags/${OLD_TAG}

Elliott Sales de Andrade · Answer 8 · Fri Jul 26 2019 05:48:38 GMT+0800 (China Standard Time)

I suggest perhaps using annotated tags as well, though I guess this was not done before.

Seb C · Answer 9 · Fri Jul 26 2019 06:30:21 GMT+0800 (China Standard Time)

Everything should be back to "normal":

go mod compliant tags (sigh)
tags pointing to correct commits
(I've dropped the x.x and vx.x tags altogether)

A small number of releases such as v3.0.1 have lost their description. That's life /shrugs

Hopefully that all hunky-dory now...

Bonne chance!

Elliott Sales de Andrade · Answer 10 · Fri Jul 26 2019 07:05:57 GMT+0800 (China Standard Time)

Thanks and sorry for all the trouble. It looks like v4.2 and v4.3 don't match the 3 forked repos I linked, i.e., v4.2->f65f8eba1329dd3387f7a10927fa122800f9daae but v4.2.0->83b26176c1ac618cfb60c6ba143e323ba28053c4 and v4.3->f95a016c71914f58426543bd4de2e1140b858573 but v4.3.0->fd2c6f246765a91c78632b38f7bc169824830015.

Strangely, the contents of the commits are the same, so I don't know what happened there.

Seb C · Answer 11 · Sat Jul 27 2019 06:04:15 GMT+0800 (China Standard Time)

Hey, yeah there's a reason for those 2. I've made an edit to the commits' environment to comply with my push policy. The file contents has not changed.

Seb C · Answer 12 · Sat Jul 27 2019 06:04:40 GMT+0800 (China Standard Time)

I'm closing this issue but if you find something wrong, feel free to re-open / update.

Seb C · Answer 13 · Sat Jul 27 2019 06:04:57 GMT+0800 (China Standard Time)

Thanks for your help and patience!