Skip to content

Restore the prerelease filter on the GitHub Pre-Release shield #3320

Closed

Description

@ptr727

Problem

The GitHub Pre-Release shield regressed to the behavior #83 fixed. #84 added filter=*-g* to the pre-release shield URL, and the repurpose in #226 dropped it. The hub's README.md and the shape spec/readme-sections.json checks now carry only include_prereleases.

include_prereleases adds prereleases as candidates but still returns the newest release. Whenever a stable release is newer than the latest prerelease, which is the state after every promotion, the badge labeled "GitHub Pre-Release" renders the stable version. With constructed tags 1.2.42 (stable) and 1.2.40-g0123456789 (prerelease), the unfiltered URL renders v1.2.42, and adding &filter=*-g* renders v1.2.40-g0123456789.

Resyncing a repository against the current hub therefore carries the regression downstream. ESPHome-NonRoot picked it up in its README resync, CodeRabbit flagged it on the promotion pull request, and it is fixed there locally.

Fix

  • Put &filter=*-g* back on the hub README.md pre-release shield.
  • Make spec/readme-sections.json require it on the GitHub pre-release shield beside include_prereleases, and cover it in spec/readme-structure.md, so the audit catches a carrier missing it.
  • Update the fixtures in spec/audit.py that build the pre-release shield URL.

NBGV prerelease tags carry a -g<sha> suffix and stable tags do not, so the glob selects exactly the prereleases.

🤖 Generated with Claude Code

Activity

  1. ptr727 commented on Oct 21, 2026

    @ptr727
    OwnerAuthor

    One limit to weigh in the fix: shields.io applies filter to the newest 100 releases only. A repository whose main publishes on its own schedule, with develop prereleases only on dispatch, can go 100 stable releases without a prerelease, and the filtered badge then renders "no matching releases found" instead of a version. That still reads as what it is, where the unfiltered badge reads a stable version as a prerelease, but the spec text could name it. Found by a local review of ptr727/ESPHome-NonRoot#321, the downstream fix.

  2. added a commit that references this issue on Oct 22, 2026
    43b1f49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions