We just had a case (PR #86) where a release's CHANGELOG entries sat under ## [Unreleased] indefinitely because nobody renamed the section and updated the compare-link footer at release time.
This repo already ships tooling that covers most of what's needed to prevent that:
StampChangelogFileWithVersion already handles Keep-a-Changelog-aware stamping — given a literal ## [Unreleased] line, it inserts ## [x.y.z] - date right after it, leaving a fresh empty ## [Unreleased] above. It's just never invoked anywhere in this repo's own build.SetReleaseNotesProperty is already dogfooded (via SIL.ReleaseTasks.Dogfood, referenced by SIL.BuildTasks.csproj / SIL.BuildTasks.AWS.csproj) to populate PackageReleaseNotes at pack time — the same extraction could feed a GitHub Release body.CreateReleaseNotesHtml could render those notes as HTML if ever wanted.
None of this is wired into .github/workflows/CI-CD.yml: there's no step that stamps CHANGELOG.md and no step that creates a GitHub Release.
Suggested direction (not a committed design):
- Use
StampChangelogFileWithVersion in a maintainer-run script or workflow_dispatch job to prepare a release PR, replacing today's hand-editing (the exact step that was skipped for v3.2.0).
- On tag push, add a CI step that extracts notes via
SetReleaseNotesProperty and creates the GitHub Release with the built packages attached, since by then CHANGELOG.md should already be correctly stamped via the step above.
New task worth adding to SIL.ReleaseTasks itself: nothing today maintains the Keep-a-Changelog compare-link footer (the [Unreleased]: .../compare/vX...master line and the per-version [x.y.z]: .../compare/vPREV...vNEW lines). This isn't specific to this repo — every consumer of SIL.ReleaseTasks that follows the Keep a Changelog format has to maintain these links by hand. A new task (either folded into StampChangelogFileWithVersion or a standalone one) that, given the changelog file, the new version, and the repo URL, updates the [Unreleased] compare link and inserts the new version's compare-link line would benefit all downstream consumers of the package, not just this repo.
We just had a case (PR #86) where a release's CHANGELOG entries sat under
## [Unreleased]indefinitely because nobody renamed the section and updated the compare-link footer at release time.This repo already ships tooling that covers most of what's needed to prevent that:
StampChangelogFileWithVersionalready handles Keep-a-Changelog-aware stamping — given a literal## [Unreleased]line, it inserts## [x.y.z] - dateright after it, leaving a fresh empty## [Unreleased]above. It's just never invoked anywhere in this repo's own build.SetReleaseNotesPropertyis already dogfooded (viaSIL.ReleaseTasks.Dogfood, referenced bySIL.BuildTasks.csproj/SIL.BuildTasks.AWS.csproj) to populatePackageReleaseNotesat pack time — the same extraction could feed a GitHub Release body.CreateReleaseNotesHtmlcould render those notes as HTML if ever wanted.None of this is wired into
.github/workflows/CI-CD.yml: there's no step that stamps CHANGELOG.md and no step that creates a GitHub Release.Suggested direction (not a committed design):
StampChangelogFileWithVersionin a maintainer-run script orworkflow_dispatchjob to prepare a release PR, replacing today's hand-editing (the exact step that was skipped for v3.2.0).SetReleaseNotesPropertyand creates the GitHub Release with the built packages attached, since by then CHANGELOG.md should already be correctly stamped via the step above.New task worth adding to SIL.ReleaseTasks itself: nothing today maintains the Keep-a-Changelog compare-link footer (the
[Unreleased]: .../compare/vX...masterline and the per-version[x.y.z]: .../compare/vPREV...vNEWlines). This isn't specific to this repo — every consumer of SIL.ReleaseTasks that follows the Keep a Changelog format has to maintain these links by hand. A new task (either folded intoStampChangelogFileWithVersionor a standalone one) that, given the changelog file, the new version, and the repo URL, updates the[Unreleased]compare link and inserts the new version's compare-link line would benefit all downstream consumers of the package, not just this repo.