Replies: 1 comment 1 reply
-
You are right, the latest release on GitHub points to the wrong tag. That’s due to the way GitHub selects the latest release: they pick the one release that has created the latest. Unfortunately, we released 1.2 first and then back ported PRs to 1.1.1 and released 1.1.1, which means 1.1.1 is marked as the latest release 😞 As you suggested, one way to work around that is to use an annotated tag instead of a plain tag, which would allow us to swap the dates in case we do a backport patch after the actual release. I’m not sure how to swap 1.1.1 and 1.2.0 though 🤔 |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
When I visit https://github.com/jetstack/cert-manager/releases/latest, I'm redirected to https://github.com/jetstack/cert-manager/releases/tag/v1.1.1
This seemed like a perfectly reasonable version to me as I was about to upgrade from 1.0.4 to
Latest
. But it struct me as odd since I had read discussion of 1.3.0...When I visit https://github.com/jetstack/cert-manager/releases, I see:
v1.3.0-alpha.1 Pre-release Verified
v1.3.0-alpha.0 Pre-release Verified
v1.1.1 Latest release Verified
v1.2.0 Verified
v1.1.0 Verified
I would have expected https://github.com/jetstack/cert-manager/releases/latest to take me to v1.2.0. Maybe that's naive and I should be asking for a
stable
(e.g. https://github.com/jetstack/cert-manager/releases/stable) instead.That said, do people have opinions on ensuring that
latest
points to the latest current release instead of a random service release to an old version?It looks like the approach would be something like this:
https://sartak.org/2011/01/replace-a-lightweight-git-tag-with-an-annotated-tag.html
(Depending on how much signing cert-manager is currently using.)
Beta Was this translation helpful? Give feedback.
All reactions