Please don't re-tag releases
alerque opened this issue · 5 comments
The v0.9.2 tag was issued twice. I built the Arch Linux package shortly after it first appeared on Jun 13th (probably within minutes). By a couple hours later when a reproducible build bot checked it, the source checksum had changed, meaning the tag had been deleted and re-posted. The package has show up as non-reproducible since. Please don't do that, this is a huge pain on packagers to track down and verify that the project hasn't been tampered with in a malicious way. If something went wrong with a release tag a patch version and keep moving forward. That makes it much easier to review what changes between fixed points where packages might be proofing things.
I generally agree with you, and try to avoid re-tagging as much as possible. The 0.9.2 release was an annoying problem in that it was a failure within the release process itself. The release scripts are triggered by the versioned tags (I'm not sure that tagging a patch version would have worked at the time but I don't recall), and they hadn't been updated from Ubuntu 18.04 runners (I run the releases on the oldest available Ubuntu runners for maximal glibc compatibility). The several hours delay before re-tagging was because GitHub had shut down those runners between the 0.9.1 and 0.9.2 releases, and I did not realise that the "failure mode" for this was "your action is started, and then is left waiting forever as no runner ever picks it up", so I thought the release process was working correctly when in fact it had failed immediately.
To avoid this problem, I've altered the release scripts to be fully testable outside of releases, so that when I do tag a release, I know that the release process will run to completion. My ideal release workflow would tag at the end of the release process instead of at the beginning, but IIRC this wasn't doable when I wrote the release scripts due to weirdness about how GitHub defined "releases". At a glance it looks like this might be more viable now; I'll have a poke around and see.
As a side-note, I was completely unaware of there being an Arch Linux package for rage until you opened this issue. I see that it is named rust-rage (or "Rust Rust age"), I presume because rage was taken by the media player. Following the discussion back in 2021 in #210 (which is now outlined in the README), my preferred fallback package name (in package systems that use a global namespace) is rage-encryption. I do not know anything about Arch Linux packaging, so I don't know if it can be changed at this time, but I'd prefer to have an answer on this before I add the Arch Linux package to the README.
The 0.9.2 release was an annoying problem in that it was a failure within the release process itself. The release scripts are triggered by the versioned tags (I'm not sure that tagging a patch version would have worked at the time but I don't recall)
I understand the failure was in the release process, but it was after the tag was public. I've never seen a situation where a build failed in the release process and re-tagging would fix it (as you did) but adding a new commit (or whatever else needs to be touched for a release) and releasing a new tag with the version incremented again would would not have worked.
my preferred fallback package name (in package systems that use a global namespace) is
rage-encryption. I do not know anything about Arch Linux packaging, so I don't know if it can be changed at this time, but I'd prefer to have an answer on this before I add the Arch Linux package to the README.
Package name changes are not easy, but possible. The pattern of adding the language ecosystem as a prefix when there are conflicts is pretty standard (both per Arch guidelines and elsewhere) but if the upstream project has a preferred way of resolving the conflict we do try to follow suit. I think the Arch packaging predates the openSUSE precedent, but given your preference for it we might be able to rename. I'll look into it.
While we're on the topic would you rather keep the current status quo where the binary is called rage and thus conflicts with the other project and people can only install one or the other, or should I rename the binary as well to match the package name so people can install both?
The Arch Linux package has been renamed to rage-encryption. Currently the binary name is still rage and it cannot be installed on the same system as the rage package. If you as the upstream think that should be changed (or anybody else comes along and wants this to change) it would be nice if you could open an issue (link on the packaging page) to request that.
While we're on the topic would you rather keep the current status quo where the binary is called rage and thus conflicts with the other project and people can only install one or the other, or should I rename the binary as well to match the package name so people can install both?
Yes I prefer this status quo, per my rationale in #210.