Have a lot of the old tags been deleted?

[paddyroddy]

I was using 2.1.14 and have previously used 2.1.17. These no longer exist. I'm currently running into bugs in a lot of the recent tags and release candidates so currently blocked.

[decyjphr]

Yeah I had deleted those tags since they were old. I can recreate it. You just need the tag/release created right?

[beatngu13]

Uhm, yes please. I assume quite a few users depend on (not so old) release tags like 2.1.17.

[decyjphr]

Ok, recreated 2.1.14 and 2.1.17 tags

[decyjphr]

Ok, sorry about that. I will keep tags around for a year in the future.

[paddyroddy]

This seems like an unusual design choice. My opinion is tags can hang around forever. I want to upgrade to, say, 2.19.0 but I'm running into #955, so I cannot safely upgrade.

[decyjphr]

Yeah, it was not expected. I deleted the releases in GitHub but that also deleted the tags.

[beatngu13]

Both tags and releases can (actually should) stay there forever, I suggest to treat them as immutable. Please reconsider your design choice. 🙏

[sdernbach-ionos]

Could you please also recreate 2.1.18? We are also running into the problem since today and I can't upgrade to 2.1.19 as of #955 and also not downgrade to 2.1.17 as of #748

[decyjphr]

2.1.18 has been recreated @sdernbach-ionos

[dannywarren]

Can you please give background on what happened here @decyjphr? Deleting all release history older than a week looks like an indication of a security incident, which is very concerning for a project that is supposed to be trusted to manage the security of GitHub repos.

[decyjphr]

@dannywarren It was an overly optimistic action on my part. I ran a script to delete releases that were older than Jan 1, 2026. I generally wanted to clean up old releases and did not realize that many customers are relying on older releases.

In hindsight it looks like a terrible idea for an open source project and I wish this didn't happen. Apologies and hope to do better next time.

[dannywarren]

Thank you @decyjphr appreciate the transparency here.

I want to note that github/safe-setting's own documentation suggests pinning the GitHub Actions run to a specific release tag (a very common concept for Actions) which is another vote for keeping tags and releases around forever.

https://github.com/github/safe-settings/blob/main-enterprise/docs/github-action.md

jobs:
  safeSettingsSync:
    runs-on: ubuntu-latest
    env:
      # Version/tag of github/safe-settings repo to use:
      SAFE_SETTINGS_VERSION: 2.1.17

Removing a tag/release is something that should really only happen if there is a security incident severe enough that having teams drop everything and investigate why the tool stopped working is the lesser of two evils compared to letting the security incident continue.

That is likely what several of us came here to confirm and were confused to see that there was no incident.

[decyjphr]

Sounds good I will create a ruleset for tags to block deletion of released tags while still allowing for deletion of pre-release tags (rc, alpha, beta, etc.) Will also modify the automation so that released versions are not deleted.

[dannywarren]

Thank you @decyjphr that would be great! Might be a handy ruleset that other repos should use as well, so if you end up with a good ruleset config for that for safe-settings I'd love to borrow it for myself.

[slaughtr]

Am I wrong that the full-sync npm script was removed during re-publishing of 2.1.14?

Been on 2.1.14 via github actions for ~16 months using the full-sync script just like the current docs example shows without issue. I had to double check Git blame to make sure I wasn't hallucinating that I'd been using npm run full-sync because it definitely does not appear in the package.json for that tag version

This is really messing with my day/week. The version that did work no longer does, all versions after it have bugs that prevent a full run. Not sure what the right path of action is here, this is a new situation for me for sure.