How to keep track of broken releases?

I spent considerable time googling around, but found nothing that would answer my question, so here it is.

If you do a canary release, and you learn the the release is somehow broken: how to you denote that a certain tag is broken and should not be deployed anywhere else, but removed from your productions ASAP?

I had several ideas:

-
Using GitLab, I could add something like broken to tag release note. Deploy jobs would call GitLab API to ensure that the tag I want to deploy is not annotated as broken.

-
I could have a text file in repo, where broken tags would be listed. In this case deploy job checks if the tag you want to deploy is not listed in the file.

-
Do no save information about release problems: just deploy a new stable, patched version to production and never look back.

How do/would you handle this? Any tips or hyperlinks are welcome.

I am not sure about other approaches, but the one that I use is a modification of #3.

There's usually a classification of releases (for example think of Ubuntu LTS and regular release).

• For the regular release, I would just release a new version and add a new tag.

• For LTS/Stable releases I would delete a tag pointing to a faulty release or change a commit this tag points to

StackExchange DevOps Q#11441, answer score: 2