i thought some words about what happens *after the release* could be
worth adding to the release guide 😋
5.5 KiB
The release process of Nushell
0. Release direct dependencies
Note
the following procedure is the same fornu-ansi-term
andreedline
and needs to be repeated
Warning
releasenu-ansi-term
beforereedline
andreedline
before Nushell
Note
nu-ansi-term
is typically released only when there are changes to publish.reedline
is typically released on the same schedule as Nushell.
Note
in the following,dep
denotes either thereedline
or thenu-ansi-term
remote e.g.https://github.com/nushell/reedline
orgit@github.com:nushell/nu-ansi-term
, depending on the dependency being installed
- bump the version (example with
reedline
andnu-ansi-term
) - get the latest revision with
git pull dep main
- publish the crate with
cargo publish
(need to be a member of the publishing team) - tag the project with
git tag v0.xx.0
- push the release tag with
git push dep main --tags
- publish the release (include the (breaking) changes and take inspiration from the other releases)
- bump the version on the Nushell side (example with
reedline
) (reference the release notes for courtesy)
1. Minor bump of the version (example)
- in the repo of Nushell, run
/path/to/nu_scripts/make_release/bump-version.nu
- Also commit
Cargo.lock
AFTER running a Cargo command likecargo check --workspace
2. Tag the nushell
repo
Warning
this is maybe the most critical step of the whole release process!! this step, once pushed to GitHub will trigger the release workflows.
Note
in the following,nushell
will be used to pull and push to thenushell
repo, e.g. thenushell
remote would behttps://github.com/nushell/nushell
orgit@github.com:nushell/nushell
- get the latest version bump commit with
git pull nushell main
- run
cargo build
to check if it's ok and check last features - tag the project with
git tag 0.xx.0
- ⚠️ push the release tag to GitHub
git push nushell main --tags
⚠️
👉 check the CI jobs
👉 check that there is the same number of targets compared to last release
3. Publish nu
to crates.io
- check the order of dependencies with
nushell/nu_scripts/make_release/nu_deps.nu
from thenushell
repo - release the Nushell crates
nushell/nu_scripts/make_release/nu_release.nu
from thenushell
repo
Note
if there is a new crate, you must add it to thegithub:nushell:publishing
group (cargo owner --list
)
Note
if a step fails
- ask the owner to
cargo owner --add github:nushell:publishing
- edit the
nu_release.nu
script to start again where it failed- re-run the script
4. Publish the release note on the website
Note
the scripts have been written in such a way they can be run from anywhere
- inspect the merged PRs to write changelogs with
./make_release/release-note/list-merged-prs nushell/nushell
- reorder sections by priority, what makes the most sense to the user?
- paste the output of
./make_release/release-note/list-merged-prs nushell/nushell --label breaking-change --pretty --no-author
to the "Breaking changes" section - make sure breaking changes titles are clear enough
- paste the output of
./make_release/release-note/get-full-changelog
to the "Full changelog" section - mark as ready for review when uploading to crates.io
- land when
- fully uploaded to crates.io
- before the GitHub release
5. Publish the release on GitHub
- go to the draft release on the release page
- grab the message of last one
- wait for the website to publish the release (in the actions tab and on the website)
- publish the release on GitHub
6. social media
- post a status update on Discord
- tweet about the new release
7. Create the next release note PR on the website
- run
./make_release/release-note/create-pr 0.xx.0 ((date now) + 4wk | format date "%Y-%m-%d" | into datetime)
8. Bump the version as development
/path/to/nu_scripts/make_release/bump-version.nu --patch
After the release
The main things to do once a release has been published are
- landing PRs marked with the
wait-until-after-nushell-release
label which have been already approved - listening to the community for feedback