with one click
release-prep
// Prepare a coreos-installer pre-release PR with dependency updates and release notes
// Prepare a coreos-installer pre-release PR with dependency updates and release notes
| name | release-prep |
| description | Prepare a coreos-installer pre-release PR with dependency updates and release notes |
pre-release-{VERSION} branch from mainCargo.toml diff since last release for version bound reviewcargo update and commits the lockfile changedocs/release-notes.mdcoreos-installermain branch (or will checkout to it)cargo is availabledocs/release-notes.md exists with an "Upcoming" unreleased section at the top# Prepare release for a specific version
/release-prep 0.27.0
# Prepare release, automatically determining the next version
/release-prep
If the user provided a version number, use that. Otherwise, read the current version from the top of docs/release-notes.md — it will have a line like:
## Upcoming coreos-installer X.Y.Z (unreleased)
Extract X.Y.Z as the RELEASE_VER.
Validate:
docs/release-notes.md matches this version# Extract version from release notes
head -10 docs/release-notes.md
# Check current branch and status
git status
# If not on main, ask user before switching
git checkout main
git pull origin main
If there are uncommitted changes, STOP and warn the user.
git checkout -b pre-release-${RELEASE_VER}
Show the diff of Cargo.toml since the last release tag so the user can review for unintended version bound increases:
git diff $(git describe --abbrev=0) Cargo.toml
Present this diff to the user and ask if everything looks correct. If the user identifies issues, STOP and let them fix manually.
cargo update
Then commit the lockfile:
git add Cargo.lock && git commit -m "cargo: update dependencies"
If Cargo.toml was also modified (e.g., resolver changes), include it:
git add Cargo.lock Cargo.toml && git commit -m "cargo: update dependencies"
Get all commits since the last release tag, excluding merge commits and automated Sync/dependabot commits:
# Find the last release tag
git describe --abbrev=0
# List commits since then
git log --oneline --no-merges $(git describe --abbrev=0)..HEAD
Categorize each commit into one of four buckets based on these rules:
Major changes — User-facing features or significant behavior changes:
signing-keys:)Minor changes — Small user-facing improvements or fixes:
fix, Fix)docs: but not internal)install: prefix that are small fixesInternal changes — Changes that don't affect users directly:
ci:, workflows/, .cci.)test, tests/)tree:, clippy)rootmap:, osmet:, blockdev:, zipl:)Packaging changes — Dependency and build configuration changes:
bump MSRV, rust-version)dockerfile:)Skip entirely — Do not include in release notes:
Sync repo templates commitsbuild(deps): bump commits (Dependabot auto-updates)cargo: update dependencies commit we just createdrelease-notes: commits (meta, already captured)For each non-skipped commit, write a concise release note bullet point. Use the commit message as a starting point but rewrite for clarity from a user's perspective. Follow the style of existing release notes entries — see examples below.
Based on historical entries in docs/release-notes.md:
install:, iso:, rootmap:Add Fedora {N} signing key; drop Fedora {M} signing keyBump minimum supported Rust version (MSRV) to {version}Update container to Fedora {N}Require \{crate}` >= {version}` (only when Cargo.toml lower bounds changed)Examples from past releases:
Major changes:
- Add Fedora 45 signing key; drop Fedora 42 signing key
Minor changes:
- install: Don't require the network by default
- Restore formatting of progress reporting to pre 0.24.0 behavior.
Internal changes:
- install: Simplify firstboot-args handling in config file expansion
- s390x: Use options and logic compatible with both C-based `genprotimg` and Rust-based `pvimg`
- Add initial TMT tests and a new workflow to execute tests on PRs
Packaging changes:
- Bump minimum supported Rust version (MSRV) to 1.85.0
- Update container to Fedora 42
- Updated core dependencies, including a major upgrade to `clap` from v3 to v4 and new versions of `nix`, `pnet`, and `sha2`.
Present the drafted release notes to the user organized by category:
Here are the drafted release notes for {RELEASE_VER}:
Major changes:
- {items}
Minor changes:
- {items}
Internal changes:
- {items}
Packaging changes:
- {items}
Please review and let me know if any changes are needed.
Wait for user confirmation or edits before proceeding.
docs/release-notes.mdOnce the user approves the release notes, edit docs/release-notes.md:
Change the "Upcoming" header from:
## Upcoming coreos-installer {RELEASE_VER} (unreleased)
to:
## Upcoming coreos-installer {NEXT_VER} (unreleased)
where NEXT_VER is the next minor version (increment Y in X.Y.Z).
Insert a new empty section for the next unreleased version right after # Release notes:
## Upcoming coreos-installer {NEXT_VER} (unreleased)
Major changes:
Minor changes:
Internal changes:
Packaging changes:
Update the current release header to include today's date:
## coreos-installer {RELEASE_VER} ({YYYY-MM-DD})
Note: Remove "Upcoming" prefix and add the date.
Fill in the release notes content under each category heading. If a category has no entries, leave it empty (blank line after the heading). Make sure any existing content that was already written in the unreleased section (e.g., signing key entries added earlier) is preserved and merged with the new content.
git add docs/release-notes.md
git commit -m "docs/release-notes: update for release ${RELEASE_VER}"
Present a summary to the user:
Pre-release prep complete for coreos-installer {RELEASE_VER}!
Branch: pre-release-{RELEASE_VER}
Commits:
1. cargo: update dependencies
2. docs/release-notes: update for release {RELEASE_VER}
Next steps from the release checklist:
1. Push and open a PR:
git push origin pre-release-{RELEASE_VER}
Then open a PR for review.
2. After PR merges, continue with the release checklist:
- git checkout main && git pull origin main
- cargo vendor-filterer target/vendor
- cargo test --all-features --config 'source.crates-io.replace-with="vv"' --config 'source.vv.directory="target/vendor"'
- cargo clean && git clean -fd
- git checkout -b release-{RELEASE_VER}
- cargo release --execute {RELEASE_VER}
Full checklist: https://github.com/coreos/coreos-installer/issues/new?labels=release&template=release-checklist.md
Ask the user if they want to push the branch and open the PR now.
If the user confirms:
git push origin pre-release-${RELEASE_VER}
Then use gh pr create:
gh pr create --title "Pre-release: coreos-installer ${RELEASE_VER}" --body "$(cat <<'EOF'
## Pre-release prep for coreos-installer {RELEASE_VER}
### Changes
- Updated dependencies (`cargo update`)
- Updated release notes for {RELEASE_VER}
### Release checklist
After this PR merges, continue with the [release checklist](https://github.com/coreos/coreos-installer/issues/new?labels=release&template=release-checklist.md).
EOF
)"
This skill automates these items from the release checklist:
git checkout -b pre-release-${RELEASE_VER} — branch creationgit diff $(git describe --abbrev=0) Cargo.toml — version bound checkcargo update + commit — dependency updatedocs/release-notes.md — drafts from git historydocs/release-notes: update for release ${RELEASE_VER}cargo release --execute — requires interactive GPG signingcargo publish — requires crates.io authcargo vendor-filterer / cargo test — post-merge verification.github/ISSUE_TEMPLATE/release-checklist.mddocs/release-notes.mdDEVELOPMENT.md (references release process)https://github.com/coreos/coreos-installer/issues/new?labels=release&template=release-checklist.md