owned this note
owned this note
Published
Linked with GitHub
# espup
1. [Prepare the release](https://github.com/esp-rs/espup/pull/368)
- Update dependencies version
- Bump `espup` version
- Check that the MSRV hasnt changed: `cargo msrv`
- Check SemVer changes with: `cargo semver-checks check-release`
- Update Changelog
2. Create the tag and release: ` git tag vx.y.z && git push --tags`
3. Create a new GitHub release: https://github.com/esp-rs/espup/releases
1. Draf new release
2. Choose the recently created tag
3. Fill the fields
- Name: vx.y.z
- Body: Copy the content from CHANGELOG.md removing empty sections
4. Remove the `Set as the latest release` tick
5. `Publish release`
4. `Continuous Deployment` action should generate all the binaries and publish to crates.io the new version
- Once the action has finished, mark the new version as latest in GitHub releases
5. Publish release info in Mattermost and Matrix
```
🚀 New `espup` release: [`v0.7.0`](https://github.com/esp-rs/espup/releases/tag/v0.7.0).
It now uses [GCC 13.2](https://github.com/espressif/crosstool-NG/releases/tag/esp-13.2.0_20230928), note that the `export-esp.sh` content will be updated, and also changes the looging messages and formatting. See full list of changes on the [release notes](https://github.com/esp-rs/espup/releases/tag/v0.7.0) or [CHANGELOG.md](https://github.com/esp-rs/espup/blob/main/CHANGELOG.md)
```
6. [Prepare next release cycle](https://github.com/esp-rs/espup/pull/370/)
# espflash
1. [Prepare the release](https://github.com/esp-rs/espflash/pull/446/files)
- Update dependencies version
- Bump `espflash`and `cargo-espflash` versions
- Check that the MSRV hasnt changed: `cargo msrv`
- Check SemVer changes for `espflash` with: `cargo semver-checks check-release`
- Update changelog
2. Create the tag and release: ` git tag vx.y.z && git push --tags`
3. Create a new GitHub release: https://github.com/esp-rs/espflash/releases
1. Draft new release
2. Choose the recently created tag
3. Fill the fields
- Name: x.y.z
- Body: Copy the content from CHANGELOG.md removing empty sections
4. Remove the `Set as the latest release` tick
5. `Publish release`
4. `Continuous Deployment` action should generate all the binaries and publish both `espflash` and `cargo-espflash` to crates.io: If done manually, make sure to publish `espflash` before `cargo-espflash`:
1. Publish `espflash`: In `espflash` folder, run `cargo publish`
2. Publish `cargo-espflash`: In `carago-espflash` folder, run `cargo publish`
6. Mark the releases as `latest`
7. Publish release info in Mattermost and Matrix
```
🚀 New `espflash` and `cargo-espflash` release: [`v2.1.0`](https://github.com/esp-rs/espflash/releases/tag/v2.1.0).
It introduces `erase-flash`, `erase-region`, and `erase-parts` subcommands and minor fixes. See full list of changes on the [release notes](https://github.com/esp-rs/espflash/releases/tag/v2.1.0) or [CHANGELOG.md](https://github.com/esp-rs/espflash/blob/main/CHANGELOG.md)
```
8. [Prepare next release cycle](https://github.com/esp-rs/espflash/pull/447/)
# Xtensa Rust (rust-build)
After esp-rs/rust has been rebased on top of the latest upstream stable:
1. Create a `build/<w.x.y.z>` branch
2. [Replace the current Xtensa Rust version in the repo for the new version ](https://github.com/esp-rs/rust-build/pull/234/files)
- Push this changes to the `build/<w.x.y.z>` branch
- A tag migth also need to be created`git tag v<w.x.y.z> && git push --tags`
3. [Create a release](https://github.com/esp-rs/rust-build/releases)
- The release name should be: `v<w.x.y.z>`
- Note that it should include the `v`. Ex: `v1.75.0.0`
- Set branch `build/<w.x.y.z>` as target branch or the created tag.
- Untick "Set as the latest release"
- Tick "Set as a pre-release"
5. Execute the [`Build Xtensa Rust toolchain` action](https://github.com/esp-rs/rust-build/actions/workflows/build-rust-artifacts.yaml)
- Run the workflow from the `build/<w.x.y.z>` branch
- Verify that the Xtensa Rust version is aready be updated due to the previous step
- Fill the "Release tag", you can get the tag by navigating to the recently created release and copying the last part of the URL
- Choose the artifacts to build
6. Wait until all builds succeed
- Some jobs may fail, fix it and rerun the job
8. Perform some testing
9. Send notification to Matrix channel about the pre-release.
10. A few days later, after some proper testing has been done, edit Release, turn off Pre-release flag, set as Latest release and Save
11. Send notification to Matrix channel about the final release.
12. Upload new image tags to [espressif/idf-rust](https://hub.docker.com/r/espressif/idf-rust)
- Manually run the [Publish IDF-Rust Tags workflow](https://github.com/esp-rs/rust-build/actions/workflows/publish-idf-rust-tags.yml) with:
- Branch of rust-build to use pointing to main if the `build/<w.x.y.z>` branch was already merged to main, or pointing to `build/<w.x.y.z>` if has not been merged yet, but the branch is ready and feature complete.
- Version of Rust toolchain should be `<w.x.y.z>`.
# esp-pacs
**TODO:** Document me! :)
# esp-hal
**TODO:** This process needs updating for the next `esp-hal` release (`0.16.0`)
## Pre-release
1. Determine which packages need releases
- `esp-riscv-rt` and `esp-hal-procmacros` are not _always_ published with each round of releases
- You can check the git history for each package to see if there have been any changes since the previous releases
2. Verify that dependent libraries still function as expected when using the updated HALs
- This will likely just be a matter of using a git/path dependency and re-building
## Release preparation
1. Bump the version numbers as needed
2. Update all `dependencies` and `dev-dependencies` for the packages which are being published
3. [Open a PR updating the version numbers, dependencies, and `CHANGELOG.md`](https://github.com/esp-rs/esp-hal/pull/887/files) for the release
- Remember to change the `Unreleased` heading in `CHANGELOG.md` to the appropriate version number, add the date, and update the corresponding link at the bottom of the document
4. Prepare PRs for dependent projects, see the post release section for the list
5. If a migration guide is required, prepare this now (awkward, or footgunnable changes should have one)
## Release
1. Publish the packages:
- _If they are being published_, then `esp-hal-procmacros` and `esp-riscv-rt` **MUST** be published prior to the other packages
- _If it is being published_, `esp-hal-smartled` **MUST** be next
- Finally, each chips-specific HAL package can be updated
- Note that `esp-hal-procmacros`, `esp-hal-common`, and `esp-hal-smartled` require `--no-verify`, but the chip-specific packages do not. This is because the aforementioned packages require a chip feature to be enabled in order to build successfully, however we do not want to publish with any of these features enabled.
2. Tag the release
3. Create a Github release with the notes and migration guide
4. Create a [PR beginning the next release cycle](https://github.com/esp-rs/esp-hal/pull/888)
- This is usually just updating `CHANGELOG.md` to have a new `Unreleased` heading with `Added`, `Changed`, `Fixed`, and `Removed` sections
## Post-release
1. Update dependent repositories:
- esp-wifi
- esp-template
- esp-flasher-stub
- esp-ieee802154
- esp-openthread
- esp-storage (only the example depends on esp-hal - updating is not mandatory)
2. Documentation run (SM: is this part of the release process already? Update: it isn't)
# esp-wifi
## Pre-release
1. Determine if `esp-wifi-sys` needs a release. We don't update the drivers very often. You can check the git history and/or the CHANGELOG.md if that is needed
## Release
1. Bump the version numbers as needed
2. Update all `dependencies` and `dev-dependencies` for the packages which are being published
3. [Open a PR updating the version numbers, dependencies, and `CHANGELOG.md`](https://github.com/esp-rs/esp-wifi/pull/424) for the release
- Remember to change the `Unreleased` heading in `CHANGELOG.md` to the appropriate version number, add the date
4. Publish the packages via `cargo publish`:
- _If it needs publishing_, then `esp-wifi-sys` **MUST** be published prior to the main package
- Publish both crates with `--no-verify`
5. Create a [PR beginning the next release cycle](https://github.com/esp-rs/esp-wifi/pull/440)
- This is usually just updating `CHANGELOG.md` to have a new `Unreleased` heading with `Added`, `Changed`, `Fixed`, and `Removed` sections
# xtensa-toolchain
1. Verify that the action is wokring with some repository that uses it
- A fork of it may be required
2. Create a tag for the release. Eg: `git tag v1.5.2 && git push --tags`
3. If its a patch version, delete the minor version in GitHub and localy:
1. Delete the tag from https://github.com/esp-rs/xtensa-toolchain/tags
2. Locally. Eg: `git tag -d v1.5`
3. Recreate it so it points at the latest patch release. Eg: `git tag v1.5 && git push --tags`
4. Create the release for the version:
- Mark the publishing to GitHub Market place
- Fill Title and Body as other releases
- Set at latest release
# esp-idf-part
1. [Prepare the release](https://github.com/esp-rs/esp-idf-part/pull/30)
- Update dependencies version
- Bump `esp-idf-part` version
- Check that the MSRV hasnt changed: `cargo msrv`
- Check SemVer changes with: `cargo semver-checks check-release`
2. Create the tag and release: ` git tag vx.y.z && git push --tags`
3. Create a new GitHub release: https://github.com/esp-rs/esp-idf-part/releases
1. Choose the recently created tag
2. Fill the fields
- Name: vx.y.z
- Body: Use generate release notes button from GH
3. `Publish release`
4. `Release` action should publish to crates.io the new version
5. Prepare next release cycle
6. Update `espflash` to use the new published version
# esp-flasher-stub
1. [Prepare the release](https://github.com/esp-rs/esp-flasher-stub/pull/61)
- Update dependencies version
- Bump `esp-flasher-stub` version
- Check that the MSRV hasnt changed: `cargo msrv`
2. Create the tag and release: ` git tag vx.y.z && git push --tags`
3. Create a new GitHub release: https://github.com/esp-rs/esp-flasher-stub/releases
1. Choose the recently created tag
2. Fill the fields
- Name: vx.y.z
- Body: Use generate release notes button from GH
3. `Publish release`