Try to detect release tags that don't make sense and offer an extra confirmation step

Created on 15 May 2025, about 24 hours ago

Problem/Motivation

Periodically releases are created with a bad tag (accidentally on the wrong major version, branches pushed instead of tags or vice versa, etc).

For infrastructure management, repeatability of builds, security, etc --- there are many reasons we don't delete releases.

Proposed resolution

We may be able to detect a release that seems to be out of order and provide an additional warning.

Remaining tasks

  • Figure out how we would analyze release tags for 'unexpected patterns'
  • Implement the warning

User interface changes

Feature request
Status

Postponed

Version

1.0

Component

User interface

Created by

🇺🇸United States hestenet Portland, OR 🇺🇸

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @hestenet
  • 🇺🇸United States drumm NY, US

    Most often I think I see the tag not being “on the branch.” The Git history can be completely arbitrary. Actually detecting this would require some walking through the commit graph since there is a valid edge case for some security releases:

    • Development on the branch has moved on, there are many commits since the last tagged release. A security release is needed and the maintainer wants to make a release with minimal changes from the last tagged release.
    • This effectively will be a branch made from the last tagged release or even a few commits after. (There doesn’t need to be a branch, tags don’t require branches.)
    • So in this case we’d be looking at the history of the branch and tag, looking for a common ancestor that is “reasonable.” That will require some careful logic, every Git commit pair in a repository has a common ancestor, usually.
Production build 0.71.5 2024