Release Process

Preface

The Zephyr SDK is released based on the timeline and plans documented in the Release Plan.

Each release may consist of one or more of the following phases:

1. Beta (x.y.z-beta*)

   • For initial testing by a small group of testers
   • Some features may not work properly

2. Release Candidate (x.y.z-rc*)

   • More stable than beta releases
   • Ready for release quality testing and validation
   • Will become a stable release if no major issues are found

3. Stable (x.y.z)

   • Fully tested stable release
   • For production use

Release Procedure

1. Ensure that the Zephyr SDK Picolibc version matches the version referenced in the manifest of the main Zephyr repository.

2. Update CMake package Kconfig version.

3. Update release-notes.md.

   • Add a new section for the release (e.g. Zephyr SDK 0.14.0).
     • The release notes may have been documented as part of feature and bug fix pull requests during development phase, in which case the Zephyr SDK vNext section listing such changes should be renamed accordingly.
     • The release sections should always be kept sorted in the descending order (latest release at the top).
   • Add the list of all changes (e.g. new features and bug fixes) since the last release under the release section.
     • If the release is a beta or a release candidate, add the changes since the last immediate release (e.g. if the current release is 0.14.0-rc2 and the last immediate release is 0.14.0-rc1, list the changes between 0.14.0-rc1 and 0.14.0-rc2).
     • If the release is a stable release, consolidate and add the changes since the last stable release; drop any changes between the non-stable releases that are not applicable to the last stable release (e.g. fix for a bug introduced in a beta or rc release).

4. Update VERSION.

   • The VERSION file must contain the version number of the release (e.g. 0.14.0, 0.14.0-rc1, 0.14.0-beta1).
   • The update must be done in a standalone commit (see 57ac6fe0dfba92276ee78a412e884d2a5b5df50f for example).

5. Create a release tag and push to the Zephyr SDK repository.

   git tag -s -m "Zephyr SDK 0.14.0-rc1" v0.14.0-rc1
   git push [email protected]:zephyrproject-rtos/sdk-ng.git v0.14.0-rc1
   

   • The tag name must be the release version number prefixed with v (e.g. v0.14.0, v0.14.0-beta1, v0.14.0-rc1).
   • The release tag must be an annotated tag that is PGP-signed by the Zephyr SDK maintainer.

6. Create and publish a GitHub release.

   • Choose the tag pushed in the previous step.
   • Release title should be in the Zephyr SDK x.y.z format (e.g. Zephyr SDK 0.14.0, Zephyr SDK 0.14.0-beta1).
   • Release description should include the release notes as well as an organised table of the download links to the release artifacts (refer to the previous release description).
   • Once the release is published through the GitHub web interface, the GitHub Actions CI will automatically build the Zephyr SDK for all supported host operating systems and upload the artifacts to the release.

7. Update Zephyr SDK Version Compatibility Matrix document.

   • The matrix must list all currently supported Zephyr releases.
   • The matrix must list at least the last three releases of the Zephyr SDK.

Quality Testing and Validation

Refer to the Quality Assurance Process document.