You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Restore the prerelease filter on the GitHub Pre-Release shield #3320
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.
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.
Activity
ptr727 commentedon Oct 21, 2026
One limit to weigh in the fix: shields.io applies
filterto the newest 100 releases only. A repository whosemainpublishes 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.Restore the Prerelease Filter on the GitHub Pre-Release Shield (#3329)
Promote the Write Guard Launcher Reads, Shield Filter, and Stand-Down…