Finding
Every release from v0.7.1 through the current v0.10.0 carries prerelease=true. Only two of the nineteen releases are flagged stable:
total releases: 19
prerelease: 17
stable: 2 -> v0.7.0, v0.2.0
GitHub excludes prereleases when resolving "Latest", so:
GET /repos/<owner>/<repo>/releases/latest -> v0.7.0
The repository page, the sidebar "Releases" badge, the latest download URLs and anything consuming that endpoint therefore all point at v0.7.0, while v0.10.0 was published on 2026-09-28. git reports 2,289 commits between the tag the endpoint serves and main.
Why this matters beyond cosmetics
- The
releases/latest endpoint is the documented way to fetch a current artifact. Any installer, script or operator following it gets a version 2,289 commits old, and gets it successfully — there is no error to notice.
- The public repository page is the first thing an outside reader sees. It currently states the project last shipped at v0.7.0.
v0.8.0, v0.9.0 and v0.10.0 are each flagged as prereleases despite being milestone releases, so no release-channel consumer can distinguish a real prerelease from a stable one.
Likely cause
A release-creation path that passes the prerelease flag unconditionally — a gh release create --prerelease or an equivalent API call in whatever publishes these tags. The flag is uniform from v0.7.1 onward, which points at a tool default rather than per-release intent.
Acceptance criteria
Evidence
Measured read-only against the repository API. The census above is from a paginated listing of all 19 releases; the v0.7.0 result is the releases/latest endpoint`s own response.
Not in scope
The question of which commits belong to which milestone release is #16803 (v0.9.0 scope, unreleased commits) and #16910. This issue is only the flag and the endpoint it misdirects.
Related: #17461 (release channels are specified but not reflected in how releases are published).
Finding
Every release from
v0.7.1through the currentv0.10.0carriesprerelease=true. Only two of the nineteen releases are flagged stable:GitHub excludes prereleases when resolving "Latest", so:
The repository page, the sidebar "Releases" badge, the
latestdownload URLs and anything consuming that endpoint therefore all point at v0.7.0, whilev0.10.0was published on 2026-09-28.gitreports 2,289 commits between the tag the endpoint serves andmain.Why this matters beyond cosmetics
releases/latestendpoint is the documented way to fetch a current artifact. Any installer, script or operator following it gets a version 2,289 commits old, and gets it successfully — there is no error to notice.v0.8.0,v0.9.0andv0.10.0are each flagged as prereleases despite being milestone releases, so no release-channel consumer can distinguish a real prerelease from a stable one.Likely cause
A release-creation path that passes the prerelease flag unconditionally — a
gh release create --prereleaseor an equivalent API call in whatever publishes these tags. The flag is uniform fromv0.7.1onward, which points at a tool default rather than per-release intent.Acceptance criteria
GET /releases/latestresolves to it rather than tov0.7.0.v0.8.0,v0.9.0,v0.10.0) are flagged according to what they actually were, rather than all being prereleases.prereleaseunconditionally; a release is marked prerelease only when it is one. Cite the file and line that sets it.latest— verify both directions, so the fix is not "clear every flag".Evidence
Measured read-only against the repository API. The census above is from a paginated listing of all 19 releases; the
v0.7.0result is thereleases/latestendpoint`s own response.Not in scope
The question of which commits belong to which milestone release is #16803 (v0.9.0 scope, unreleased commits) and #16910. This issue is only the flag and the endpoint it misdirects.
Related: #17461 (release channels are specified but not reflected in how releases are published).