Release process: main -> develop sync (step 7) is easy to skip and silently corrupts the next CHANGELOG

[placerda]

Summary

Step 7 of the release process (sync main back into develop) was skipped after v0.8.1. This left develop two commits behind main (49d413a, 02cf9ae) and would have silently corrupted the v0.8.2 CHANGELOG.

Why this is not cosmetic

cut-release.yml branches from develop and rewrites the changelog with a literal string replacement:

text.replace("## [Unreleased]", "## [Unreleased]\n\n## [<version>] - <date>", 1)

Everything under [Unreleased] becomes the content of the new version. When develop is behind main:

1. develop still carries entries that were already shipped in 0.8.1, so they get republished as new in 0.8.2.
2. develop has no ## [0.8.1] heading at all, so the release PR into main deletes the [0.8.1] section from the published changelog.

Additional trap: the fix-up merge produces a wrong result

Running git merge main into develop after the fact does not resolve cleanly in a semantic sense. main inserted ## [0.8.1] - <date> directly below ## [Unreleased], while develop had unreleased content in that same spot. The ort merge places the [0.8.1] heading above the develop content, so new unreleased entries end up nested inside an already-published version. The result is syntactically valid and easy to miss in review.

This had to be resolved by hand during the 0.8.2 release.

Suggestion

Automate it so it cannot be forgotten. After github-release succeeds in release.yml, either:

• open an automatic main → develop sync PR, or
• fast-forward develop directly when the merge is trivial.

A cheap complementary guard: have cut-release.yml fail early if git log origin/develop..origin/main is non-empty, since that state always means the previous release was not cleaned up.

References

• docs/release-process.md, section 9, step 7
• .github/workflows/cut-release.yml

[placerda]

Fixed in #380 (merged to develop as 22be788).