zk-org
v0.15.2 tag gone
Check if applicable
- [x] I have searched the existing issues (required)
- [ ] I'm willing to help fix the problem and contribute a pull request
Describe the bug
The tag for release v0.15.2 is gone. The Alpine package had to revert to the previous release.
How to reproduce?
n/a
zk configuration
n/a
Environment
n/a
I still have the tag locally, it pointed to 45b36472a9187c593cce3defd26ef89628de2488.
The release failed (see the actions)
So I deleted the tag. Is this bad practice/How should such a situation be handled? Figured it was best as the release failed.
Have pinged jurica to see if he can fix it before I get around to it, as he put his hand up to handle CI related stuff.
Nice, my first try worked and the arm containers build fine on arm hosts. But I didn't merge the PR in the zk-xcompile.
Unless there's a huge security issue or alike, it's best not to yank releases.
This upgrade had been merged into Alpine package repositories. The tag was gone by the time the production builders tried to build the packages, so the package upgrade had to be rolled back.
Being a bit pedantic: CI failed for some reason, but the release itself did not; the tag shows up fine and was had already been applied downstream downstream.
I think whichever CI jobs run for tags should also run for regular commits, so we discover failures before publishing a release.
You've pushed a different release with the same version as the old one, v0.15.2.
You should never make two releases of the same project with the same name and same version. We now have two canonical v0.15.2. Even git warns about the overlap:
From https://github.com/zk-org/zk
! [rejected] v0.15.2 -> v0.15.2 (would clobber existing tag)
Downstream distributions retain these source tarballs. They need to do this to comply with licenses, e.g.: GPL: since they're distribution builds, they need are required to make the sources available too.
Downstream consumers have cached v0.15.2(original), and v0.15.2(new) is a different release with the same number but different checksum.
There are workaround that can be taken around this, but ideally the new release should just have a new version number.
Actually, the tarball is not in Alpines cache because the tag was deleted before it was downloaded. It’s only in my own local caches