Fix four release-procedure defects found running v0.9.2 - #432
Open
dchud wants to merge 1 commit into
Open
Conversation
Section 3.1's version bump used sed's multi-line `/range/{s///}` form,
a GNU extension. BSD sed (macOS) rejects it, prints "bad flag in
substitute command", and still exits 0 — so the bump silently no-ops
and the release proceeds at the old version. Replaced with POSIX awk
and a verification step that exits non-zero on mismatch.
Section 7.1 staged three files but Section 3.3 requires sweeping the
README roadmap line, making four. Added README.md and a check for
unstaged leftovers.
Section 4.2 seeds the [Unreleased] template with Performance and
Documentation, which lint-changelog.sh did not treat as canonical, so
every run warned. Both are used in released sections (Documentation
6 times, Performance 4), so the lint was wrong, not the template.
Added them after Fixed and synced the order in both places the doc
states it.
Sections 9.1 and 9.2 wrote scratch to /tmp and used `cargo init`
inside the repo. `cargo init` appends the test project to the root
Cargo.toml workspace members and pulls the published crate into
Cargo.lock; deleting the directory leaves both behind. It also makes
the project a workspace member, so it stops resolving dependencies
like a downstream consumer and the check proves nothing. Both now use
the gitignored tmp/ and a hand-written manifest with an empty
[workspace] table, plus an assertion that cargo resolves a registry
source rather than a local path.
Merging this PR will not alter performance
Comparing Footnotes
|
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
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.
Running the v0.9.2 release end to end surfaced four defects in
docs/contributing/release-procedure.mdand one inscripts/lint-changelog.sh. All four bit during the actual release; none are hypothetical.The version bump fails silently on macOS
Section 3.1 used sed's multi-line
/range/{s///}form, which is a GNU extension. BSD sed rejects it withbad flag in substitute command— and still exits 0. The bump no-ops, and since the next step iscargo update --workspace, nothing downstream notices. A less careful run produces achore(release)commit containing no version change. Replaced with POSIXawkand a verification step that exits non-zero on mismatch.Section 7.1 contradicted Section 3.3
7.1 said stage exactly three files; 3.3 requires sweeping the README roadmap line, making four. Added
README.mdand a check for unstaged leftovers.The lint warned on its own template, permanently
Section 4.2 seeds
[Unreleased]with### Performanceand### Documentation, neither of whichlint-changelog.shtreated as canonical — so every run on every branch emitted a warning that could never be resolved. Both are genuinely used in released sections (Documentation6 times,Performance4), so the lint was wrong rather than the template. Added them afterFixedand synced the ordering in both places the doc states it. The warning is now gone.Section 9.2 mutated the repository it was verifying
Worst of the four.
cargo initinside the repo edits the rootCargo.toml, appending the test project to the workspacememberslist, and pulls the published crate into the rootCargo.lock. Deleting the test directory leaves both edits behind — they would have been committed silently ifgit statushad not been checked.It also makes the project a workspace member, so it inherits workspace lints and shares the root lockfile and stops resolving dependencies the way a downstream consumer does — meaning the check silently proves nothing. Both 9.1 and 9.2 now use the gitignored
tmp/instead of/tmp, 9.2 writes its manifest by hand with an empty[workspace]table, and the checklist assertscargo metadatareports aregistry+https://...source rather thanLOCAL PATH.Verification
Each fix was exercised rather than assumed: the
awkbump was run against a copy ofCargo.tomland confirmed to change only the[workspace.package]line;lint-changelog.shnow exits 0 with no warning; the 9.2 isolation flow is the corrected one I actually used to verify 0.9.2 on crates.io..cargo/check.shpasses.No changes to release semantics — same steps, same order, same artifacts.
Checklist
.cargo/check.shpasses locallyCHANGELOG.mdupdated under[Unreleased]— N/A, contributor-facing tooling with no user-visible effect🤖 Generated with Claude Code