Quality Assurance Process

DISCLAIMER

This is a preliminary document explaining what should be done before releasing a new version of Zephyr SDK.

Note that the process documented here is not formal nor is it strictly enforced; it is only intended to serve as a recommendation for the SDK release managers. There may be numerous exceptions and deviations made for each SDK release, depending on the nature of the release and the amount of changes involved.

Overview

The Release Quality Assurance Process shall consist of, at minimum, the following components:

• Integration Test
• Footprint Validation

Integration Test

The purpose of an integration test is to ensure that the current and, if applicable, previous Zephyr codebases are compatible with an SDK release and all Zephyr tests and samples can be successfully built using it.

An integration test shall:

• build all Zephyr tests and samples on the default platforms.
• run all Zephyr tests and samples on the emulate-able platforms.
• begin when the first Release Candidate (RC) is published.
• be performed using the latest Zephyr development branch (main) and, if applicable, using all compatible previous Zephyr release tags.

The recommended strategy for performing an integration test is as follows:

1. Integrate the latest Release Candidate (RC) release into the CI and User Docker images.
2. Update the Continuous Integration (CI) workflows of the zephyr-testing repository to use the updated CI Docker image.
3. Build and run Zephyr tests and samples using the Twister workflow.

Footprint Validation

To be documented