Please don't retag releases!

[alerque]

Once a tag is pushed to this repo, please consider it immutable. You have to control over the timeline of downstream usage. I've already bumped the Arch Linux package and sent it to the testing repository, now I see the last tag (1.85.0) was removed and re-tagged. Now I have to spend ten times as much time as it took to bump the package in the first place to handle the anomaly. First it breaks the "trust on first use" model, so I have to figure out if the release is even legit. Then I have to come up with a way to break the build systems cache to flush out the old source files, artificially bump the package version to get a rebuild that people can upgrade to, and so on.

If something goes wrong with the release process and there are post-release changes of any kind, just tag a new patch release and let everybody move forward normally please. Thanks.

[DanBloomberg]

I'm very sorry to have caused you all this trouble.

I will explain what happened. I go through a fairly complex testing process before doing a release. But in this case I had not properly saved the new release number in the build command files, so the tag that said 1.85.0 was inconsistent with the library it built, which had a 1.84.1 version number. This is a serious error. I did not want a release with that error to exist, so I deleted the release. I also had to delete the old tag, because I couldn't re-use it with a proper 1.85.0 release -- in that case, the autotools enabled tarball would not be consistent with the 1.84.1 versioned source referred to by that tag.

Here's a proposal that should avoid this in the future. When I make a release, I will label it as a pre-release, and only change that to an actual release after a week without problems. And once it's changed to a release, it will never be removed. Does that make sense?

[amitdo]

#721 (comment)