-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Kops releases - prefix git tags with v #8373
Conversation
v
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rifelpet The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Yes, we should adopt the "v" prefix. I thought we would have to do both, so I did it for 1.11.0 IIRC, but then I guess I forgot to make it systematic so I stopped doing it :-( Should we support both? I don't think it costs us much to do so, and it shouldn't break anyone, but I also don't see how we ever discover if people are relying on the form without the "v" if we keep supporting it... |
We have a chance to find any of our own reliance on the non-prefixed tag through alpha/beta releases. We also have the option of tagging without the prefix at a later time. I would lead with prefix only for 1.18. Maybe 1.17. I wouldn't object to both for 1.16. |
Go modules require the v prefix [0], and k/k also tags with the v prefix [1] We have some inconsistent tags already, for 1.11.0 we have tags of both `1.11.0` and `v1.11.0` which is the most recent tag with the prefix. This is also why 1.11.0 is the default version imported by `go get`: ``` go get -v k8s.io/kops go: downloading k8s.io/kops v1.11.0 ``` and the latest version in `go list`: ``` go list -m -versions k8s.io/kops k8s.io/kops v1.4.0-alpha.1 v1.4.0 v1.4.1 v1.4.2 v1.4.3 v1.4.4 v1.10.0 v1.11.0 ``` I'm proposing we switch to only tagging with the v prefix. I'm only updating the actual git tag and not the entire version string used throughout kops due to its larger impact: * Output by `kops version` * Public URLs for kops assets * Protokube tag I'm hoping this is the least invasive way we can make this change. If we think advanced notice is required, we could tag with both formats for a number of releases before tagging only with the v prefix. [0] https://github.com/golang/go/wiki/Modules#modules [1] https://github.com/kubernetes/kubernetes/releases/tag/v1.17.0
10e36fb
to
9349222
Compare
Ok, I've updated it so that now both tags are created, and the GH Release is created off of the v prefixed one only. The Similar to many of our other recent changes, we could tag both in 1.16 stable and announce that 1.18 will only be tagged with the v prefix. We could also consider retroactively creating v prefixed tags because as you mention, they dont cost anything. I'm fairly certain we can fake the git timestamp so that GH still sorts them in order. Perhaps we do this after tagging 1.16 stable, just for posterity? |
/hold cancel We'll want to cherry-pick this back to all active branches as well. |
/lgtm |
…73-upstream-release-1.16 Automated cherry pick of #8373: Prefix git tags with `v`
…73-upstream-release-1.17 Automated cherry pick of #8373: Prefix git tags with `v`
…73-upstream-release-1.15 Automated cherry pick of #8373: Prefix git tags with `v`
I noticed this while investigating #8371 and there have been other reports of issues when trying to import kops with go modules (I can't find the GH issues at the moment)
Go modules require the v prefix, and k/k also tags with the v prefix.
We have some inconsistent tags already, for 1.11.0 we have tags of both
1.11.0
andv1.11.0
which is the most recent tag with the prefix.This is also why 1.11.0 is the default version imported by
go get
:and the latest version in
go list
:I'm proposing we switch to only tagging with the v prefix. I'm only updating the actual git tag and not the entire version string used throughout kops due to its larger impact:
kops version
I'm hoping this is the least invasive way we can make this change.
If we think advanced notice is required, we could tag with both formats for a number of releases before tagging only with the v prefix.
/hold for Justin's approval
/cc @justinsb