chore: add the 1.57.1 changelog entry and stop auto-release tagging before the notes exist - #1707
Merged
Merged
Conversation
…efore the notes exist Unblocks two stranded tags and removes the cause, in a chore: commit so this cannot itself tag a third version. v1.57.0 and v1.57.1 are both pushed with no published release. The cause is a process defect I hit three times: auto-release computes the version from the commit type AND the previous tag, then pushes the tag — and only afterwards does release.yml check that CHANGELOG.md has a section for it. So a version I could not know in advance gets tagged, the release fails on the missing section, and the next fix: merge (including one meant to repair this) tags another one. Patching the number by hand could never converge. Two changes: 1. The 1.57.1 entry the release needs, describing the Bandwidth Monitor chart crash fixed in #1706, and csproj moved to 1.57.1 to match. That is the tag whose release will be re-dispatched; v1.57.0's content is already inside 1.57.1, so nothing shipped is lost or rewritten. 2. auto-release now verifies the CHANGELOG entry exists and is non-empty BEFORE creating the tag. A missing entry now costs a workflow re-run instead of stranding a version. The error message states the exact header to add and the bump it came from, because the author genuinely cannot compute that number locally — treating it as author carelessness would be the wrong fix. Verified against six fixtures rather than assumed: an entry that is present and non-empty accepts; a missing one rejects (the actual failure); a present-but-empty section rejects, since it would publish a release with no notes; an older entry still resolves; and the escaped dots mean 1.5.71 cannot match a 1.57.1 header. Also re-ran the csproj/CHANGELOG consistency check added in #1706 against this tree so the two guards agree rather than contradicting each other. Note that release.yml checks out the TAG, not main — so this entry only reaches a release for tags created after it. That is exactly why the guard belongs in auto-release, before the tag is cut.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Unblocks two stranded tags and removes the cause.
chore:deliberately — this must not itself tag a third version.The problem
v1.57.0andv1.57.1are both pushed with no published release. The app on GitHub is still 1.56.14.The cause is a process defect, and I hit it three times in a row:
auto-releasecomputes the next version from the commit type and the previous tag, then pushes the tag.release.ymlcheck thatCHANGELOG.mdhas a section for that version.fix:merge (including one meant to repair this) tags another one.Patching the version by hand could never converge. That's why this is
chore:.What this changes
1. The 1.57.1 entry the release needs. Describes the Bandwidth Monitor chart crash fixed in #1706, with csproj moved to
1.57.1to match.v1.57.1is the tag whose release will be re-dispatched; v1.57.0's content is already contained in 1.57.1, so nothing that shipped is lost or rewritten.2.
auto-releasenow verifies the CHANGELOG entry before creating the tag. A missing entry costs a workflow re-run instead of stranding a version. The error message states the exact header to add and which bump produced it — the author genuinely cannot compute that number locally, so treating this as carelessness would be the wrong fix.Verification
Six fixtures, not assumptions:
1.5.71vs a1.57.1header (escaped dots)The last row matters: the two guards have to agree rather than contradict each other.
Follow-up after merge
release.ymlchecks out the tag, not main — so this entry only reaches a release for tags created after it.v1.57.1therefore needs a manualReleasedispatch once this lands, which I'll do and verify (notes, SHA256, discussion, winget). That tag-vs-main split is precisely why the new guard belongs inauto-release, before the tag is cut.No version bump beyond aligning to 1.57.1, and no new CHANGELOG section for this commit itself —
chore:doesn't release.