Repository navigation
Key catalogue releases by version and preserve history - #8
Conversation
Send the plain semver version as the release tag instead of the git tag: the API and site sort and compare releases by semver tag, and the site derives the editable version from it. Prepend to the published release history (same-tag re-runs replace in place, capped at 100) instead of submitting only the newest entry.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
This comment was marked as low quality.
This comment was marked as low quality.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b43f149753
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
A pre-fix entry keyed by git tag counts as the same release as its version, so re-publishing replaces the twin instead of doubling it. Non-matching legacy entries are preserved.
This comment was marked as low quality.
This comment was marked as low quality.
|
Codex Review: Didn't find any major issues. Delightful! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
The publisher sent the git tag (
branding-v0.8.9) as the releasetag, but that field is the semver key the whole stack compares on: the API partitions non-semver tags out of ordering, the site's semvergt/ltthrows on them, its edit form derivesversionfromtag, and core's updater takes the first release as latest. Send the plain version instead; the git tag stays reachable via changelog and download URLs.Also prepends to the published release history (fetched with the machine token, now passed to the build step) instead of submitting only the newest entry. Same-tag re-runs replace in place, capped at the schema's 100, unknown future fields stripped, and any non-404 fetch failure fails the build loudly rather than silently wiping history.