update release_checklist.md
diff --git a/doc/dev/release_checklist.md b/doc/dev/release_checklist.md index 5541d5e..fc2ff4b 100644 --- a/doc/dev/release_checklist.md +++ b/doc/dev/release_checklist.md
@@ -5,11 +5,6 @@ We'll use `v4.6.0` as the intended release version as a running example. -- One week before the planned release, ensure that - (1) someone has written the release notes and - (2) someone has written the first draft of the release blog post. - If there is any material in `./releases_drafts/` on the `releases/v4.6.0` branch, then the release notes are not done. - (See the section "Writing the release notes".) - `git checkout releases/v4.6.0` (This branch should already exist, from the release candidates.) - `git pull` @@ -86,7 +81,7 @@ - Toolchain bump PR notes: - In addition to updating the `lean-toolchain` and `lakefile.lean`, in `.github/workflows/lean4checker.yml` update the line - `git checkout v4.6.0` to the appropriate tag. + `git checkout v4.6.0` to the appropriate tag. - Push the PR branch to the main Mathlib repository rather than a fork, or CI may not work reliably - Create and push the tag - Create a new branch from the tag, push it, and open a pull request against `stable`. @@ -139,16 +134,13 @@ git checkout -b releases/v4.7.0 ``` - In `RELEASES.md` replace `Development in progress` in the `v4.7.0` section with `Release notes to be written.` -- We will rely on automatically generated release notes for release candidates, - and the written release notes will be used for stable versions only. - It is essential to choose the nightly that will become the release candidate as early as possible, to avoid confusion. +- It is essential to choose the nightly that will become the release candidate as early as possible, to avoid confusion. - In `src/CMakeLists.txt`, - verify that you see `set(LEAN_VERSION_MINOR 7)` (for whichever `7` is appropriate); this should already have been updated when the development cycle began. - `set(LEAN_VERSION_IS_RELEASE 1)` (this should be a change; on `master` and nightly releases it is always `0`). - Commit your changes to `src/CMakeLists.txt`, and push. - `git tag v4.7.0-rc1` - `git push origin v4.7.0-rc1` -- Ping the FRO Zulip that release notes need to be written. The release notes do not block completing the rest of this checklist. - Now wait, while CI runs. - You can monitor this at `https://github.com/leanprover/lean4/actions/workflows/ci.yml`, looking for the `v4.7.0-rc1` tag. - This step can take up to an hour. @@ -248,15 +240,12 @@ # Writing the release notes -We are currently trying a system where release notes are compiled all at once from someone looking through the commit history. -The exact steps are a work in progress. -Here is the general idea: +Release notes are automatically generated from the commit history, using `script/release_notes.py`. -* The work is done right on the `releases/v4.6.0` branch sometime after it is created but before the stable release is made. - The release notes for `v4.6.0` will later be copied to `master` when we begin a new development cycle. -* There can be material for release notes entries in commit messages. -* There can also be pre-written entries in `./releases_drafts`, which should be all incorporated in the release notes and then deleted from the branch. +Run this as `script/release_notes.py v4.6.0`, where `v4.6.0` is the *previous* release version. This will generate output +for all commits since that tag. Note that there is output on both stderr, which should be manually reviewed, +and on stdout, which should be manually copied to `RELEASES.md`. + +There can also be pre-written entries in `./releases_drafts`, which should be all incorporated in the release notes and then deleted from the branch. See `./releases_drafts/README.md` for more information. -* The release notes should be written from a downstream expert user's point of view. -This section will be updated when the next release notes are written (for `v4.10.0`).