medcore-cut-release

Automating a GitHub release from a green CI workflow involves validating the release.yml run status, moving CHANGELOG entries to a new version section, tagging HEAD, and publishing the release with extracted notes. This automates pre-flight checks and tag creation in one step.

Keeping a fresh [Unreleased] block when stamping a Keep-a-Changelog file requires moving current entries into a new version section while inserting an empty [Unreleased] placeholder above it, ensuring the changelog layout remains valid for future updates before tagging HEAD.

Yes, the release automation process checks if the main branch CI is green before tagging. It performs safe pre-flight validation to confirm the release.yml workflow has passed successfully on main before stamping the CHANGELOG and cutting a release.

Extracting versioned release notes from a CHANGELOG within GitHub limits requires deterministic extraction of the specific version section. The process slices the correctly formatted Keep-a-Changelog section and uses it directly as the published GitHub release body.

You should avoid using gh release create --target for cutting releases because it can result in invalid tag targeting. The correct approach creates an annotated tag at HEAD after the stamp commit, then publishes a non-draft release using the extracted CHANGELOG notes.

Determining patch, minor, or major version bumps from commits involves analyzing commit history since the previous tag and checking for documented breaking changes. This rationale derives the appropriate semantic version bump for the new release section.