Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add v prefixed release tags #1201

Closed
jpreese opened this issue Dec 13, 2019 · 8 comments · Fixed by istio/release-builder#100
Closed

Add v prefixed release tags #1201

jpreese opened this issue Dec 13, 2019 · 8 comments · Fixed by istio/release-builder#100

Comments

@jpreese
Copy link

jpreese commented Dec 13, 2019

When consuming modules from Go, the Go toolchain expects tags to start with v.

Going forward, could a tag be added that contains the v prefix? It would be nice to add some retroactively as well. Thanks!

@howardjohn
Copy link
Member

Is v a hard requirement, I thought it supported both forms?

@jpreese
Copy link
Author

jpreese commented Dec 13, 2019

It is a hard requirement. If the module that you're referencing does not have tags prefixed with v, it won't resolve correctly and some manual intervention is required.

@howardjohn
Copy link
Member

Thanks, I didn't realize that. I think we have some code that expects to not have a v prefix, so we would need to have double tags probably.. or more precisely we have code that looks at the version string in the code. I supposed we could tag with v but set the version without v.

We do not follow proper semver though, so fixing this may cause some problems there as well

fyi @jasonwzm probably even more relevant for client-go

@jpreese
Copy link
Author

jpreese commented Dec 13, 2019

client-go is also relevant. If you're trying to keep them in sync, double tagging may also help as client-go currently will keep grabbing the latest Istio API (references istio.io/api v0.0.0-20191109011911-e51134872853)

@howardjohn
Copy link
Member

We would need to do more than double tagging for that right? eg if we release 1.5.1, we tag both repos v1.5.1, but then we need to update go.mod in client-go to point to istio.io/api@v1.5.1?

@jpreese
Copy link
Author

jpreese commented Dec 13, 2019

That is correct, yes.

Right now I'm using client-go (which requires istio.io/api), but in my go.mod they have different dates on them. It hasn't caused any problems that I'm aware of, but just a thought if the goal is to keep them in sync.

my go.mod

...
	istio.io/api v0.0.0-20191205234547-d2b87eef5659
	istio.io/client-go v0.0.0-20191206191348-5c576a7ecef0

@jasonwzm
Copy link
Member

For client-go which is user-facing, we can tag the repo with v versions. We can follow something here: https://github.com/kubernetes/client-go/blob/master/INSTALL.md#add-client-go-as-a-dependency

But for Istio internal usage of different go modules, we currently use sha to import a repo, which is intended. For pseudo versions in go modules, the difference in timestamps are fine as long as they are using the correct sha for each repo.

@howardjohn can you help adding double tagging for client-go in the next release? I could not find the release checklist doc.

@howardjohn
Copy link
Member

@jasonwzm its all automated in istio/release-builder. Under publish/github there should be stuff about tagging

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants