Note the following procedure is the same for nu-ansi-term and reedline and needs to be repeated

Warning release nu-ansi-term before reedline and reedline 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 the reedline or the nu-ansi-term remote e.g. https://github.com/nushell/reedline or [email protected]:nushell/nu-ansi-term, depending on the dependency being installed

• bump the version (example with reedline and nu-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)

• in the repo of Nushell, run /path/to/nu_scripts/make_release/bump-version.nu
• then, ensure there are no compilation errors with any combination of features by running:

  cargo hack --all --feature-powerset --skip default-no-clipboard,stable,wasi,mimalloc check

  (this will take a while...)
• check for build errors by running:

  cargo hack --all build

  (this will build each crate with default features)
• commit changes with bumped versions (this includes changes to Cargo.lock)

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 the nushell repo, e.g. the nushell remote would be https://github.com/nushell/nushell or [email protected]:nushell/nushell

• get the latest version bump commit with git pull nushell main
• 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

• check the order of dependencies with nushell/nu_scripts/make_release/nu_deps.nu from the nushell repo
• release the Nushell crates nushell/nu_scripts/make_release/nu_release.nu from the nushell repo

Note if there is a new crate, you must add it to the github: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

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

• 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

• post a status update on Discord
• tweet about the new release

• run ./make_release/release-note/create-pr 0.xx.0 ((date now) + 4wk | format date "%Y-%m-%d" | into datetime)

• bump the patch version on nushell (example) by running

/path/to/nu_scripts/make_release/bump-version.nu --patch

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