Release Stages
This guide provides insights and definitions for the various release stages of a component, function, product, or system.
During the development of new products, functions, or components, release stages are used to describe the level of maturity of the coming release. The release stages are alpha, beta candidate, beta, release candidate, and release.
Note: This guide references multiple checklists, which can be found in different sections of the 3BSE061530 Checklist for Beta, IVA, and Start of Type Test, even if they are not included in the document title.
Intended for
Release owners.
Release stages - overview
The table below gives an overview of the maturity level and use of the different release stages.
| Alpha | Beta candidate | Beta | Release candidate | Release |
|---|---|---|---|---|
| - Functionality not complete. - Not fully tested. | - (Close to) full functionality. - Component and product test initiated. - User documentation available as drafts. | - Full functionality. - Component test completed. - Partly product/system tested. | - Product version aimed to be released. - Formal product and system tests executed. | - Final version, market release. - Release acceptance test. - Safety validation test (for safety products). - Media verification. |
| - Early integration & testing (no external distribution). | - Internal interim use. - External test labs. | - Formal product/system test. - At selected beta sites. | - Final tests (no major changes expected ahead). | - Release. |
In Azure DevOps (ADO), there are “only” three artifacts relating to the maturity level of a release, mapping to the release stages like this:
| Artifact in ADO | Release stage |
|---|---|
| - Local | - Unclassified (e.g. daily build, pull request) - Alpha |
| - Prerelease | - Beta candidate - Beta - Release candidate |
| - Release | - Release |
Release stages - descriptions
Alpha version (α)
An alpha (α) version is a pre-release version where functionality is not yet complete, and has not been fully tested. A clear description in the “version notes” (or similar) is required, outlining which functionality is available and which is not.
Alpha quality in a function/component is not sufficient to permit distribution to external customers or users. An alpha version is used by other functions/components and products under development for early integration and testing.
Beta versions
There are two different beta versions: beta candidate and beta. Both are pre-release versions. The acceptance criteria for the two beta versions are described in the following sections, and the main differences between the versions are described in this table:
| Beta candidate | Beta |
|---|---|
| A beta candidate has full or nearly full functionality. In cases where some functionality is missing, it should be well defined and communicated to the receiver (e.g. in a version note or release note). | A beta always has full functionality. |
| Beta candidates are intended for interim use as “internal betas”. Internal and external test labs may also use them to build a system environment when testing products and systems. | A beta has a higher quality level than a beta candidate and has undergone a longer test time. See the Beta checklist for details. |
| A beta candidate may, in restricted cases, be used at beta sites in limited and non-critical areas, e.g. during engineering work at a customer site. | A beta may be used for shipments to agreed-upon beta sites. |
Beta candidate version of a product (βC)
A beta candidate version of a product (e.g. a stand-alone product, a product part of a system, or a system) has full functionality, or close to full functionality. A formal decision is required to determine whether the product is in the beta candidate stage, and this decision shall be documented in the Beta checklist.
The following criteria define the quality expected for the beta candidate release stage of a product:
- The product has full or nearly full functionality, according to the requirements and epics. In cases where functionality is missing, the scope of included and missing functionality in the beta candidate shall be well-defined and documented in "version notes" (or similar).
- A formal component test has been executed.
- An informal product test has been executed.
- Integration tests have been executed, including tests with other dependent products (if applicable).
- For hardware, informal tests of hardware and firmware have been executed.
- User documentation, including the installation guide, is available as drafts.
Beta version of a product (β)
A beta version of a product (e.g. a stand-alone product, a product part of a system, or a system) has full functionality. A formal decision is required to determine whether the product is in the beta stage, and this decision shall be documented in the Beta checklist.
The following criteria define the quality expected for the beta release stage of a product:
- The product has full functionality according to the requirements and epics.
- All the above quality criteria for beta candidate versions are fulfilled.
- Digital code signing: the product is release-signed (using external certificates).
- Pre-DSAC has been executed with findings documented and accepted.
- 3rd party software OSS scan has been executed with findings documented and accepted.
- Cyber security assessment executed with findings documented and accepted.
- An informal product test has been executed with findings documented and accepted.
- An informal system test has been executed with findings documented and accepted.
- Start of product type test criteria are fulfilled according to the Start of PTT checklist.
- Start of system type test criteria are fulfilled (if applicable) according to the Start of STT checklist.
To increase test coverage, beta versions can be shared with customers designated as beta sites.
Note: The shipment of beta versions to customers shall always be done with the expressed understanding by the customer that:
- The product is a beta version.
- Any tests shall be executed in accordance with the beta test program instructions (if applicable).
- The product shall be subject to conditions of use as described in a signed agreement, see 3BSR000887 Field Beta Test Agreement.
Release candidate versions (RC & RC HI)
A release candidate (RC) is the product version intended for release, either as part of a system release or as a stand-alone product. All type tests are completed except for the specified release acceptance test (RAT), standard regression test (SRT), and safety validation test (SVT).
Release candidate high integrity (RC HI) is a proposed safety product version. In addition to the quality requirements for a release candidate, it shall also fulfill the quality requirements covered by Start of SVT checklist.
A formal decision is required to determine whether the product is in the release candidate stage, and this decision shall be documented in the Start of RAT checklist.
The following criteria define the quality expected for the release candidate stage of a product:
- The product has full functionality according to the requirements and epics.
- All the above quality criteria for beta candidates and beta versions are fulfilled.
- DSAC has been executed.
- A formal product test has been executed.
- A formal system test has been executed.
- "Start of RAT" criteria are fulfilled, according to the Start of RAT checklist.
Release version
The release version is the final version ready for market release.
A formal decision is required to determine whether the product is ready for market release, and this decision shall be documented in the internal validation acceptance (IVA) checklist.
The following criteria define the quality expected for the release version of a product:
- All the above quality criteria for beta candidate, beta and release candidate versions are fulfilled.
- IVA criteria are fulfilled, see the IVA checklist.
Criteria for external delivery
A beta version or a release candidate version may be used for shipments to agreed-upon beta sites. A beta candidate may in restricted cases be used at beta sites in limited and safe areas, for example during engineering work at a customer site.
An external delivery outside R&D (to divisions or end customers) can have different designations depending on the quality level, the targeted audience, and intended usage.
The following criteria define the quality expected for an external delivery of a product:
- The above quality criteria for beta versions are fulfilled (or non-fulfilled items are accepted).
- Quality for beta shipment is fulfilled (verified through e.g. installation test, regression test, and specific customer use case tests).
- 3rd-party software has been approved, and open-source software (OSS) obligations are fulfilled.
- Pre-DSAC has been executed.
- Export control classification (ECCN) has been approved.
- License handling: license or license file is available for the receiver (e.g. demo license).
- Virus scanning (using virus scanners according to defined requirements).
- Hardware modules are marked as beta components (e.g. non-removable marking/sticker).
- Explosion protection (Ex): Components to be Ex-certified must not have Ex-marking until the Ex-certification is granted.
- Safety: High-integrity controller firmware shall either not be part of the delivery (for non-HI projects) or NON-CERT-marked (for HI projects). Note that CERT-marked controller firmware is only allowed to be distributed after explicit approval from the assessor.
- Beta indication/marking in software in about boxes, logs, and user interfaces (if applicable).
- A support strategy is defined, and the support organization is trained.
- The external receiver and the internal accountable have signed a beta agreement.
- The “PA PCP Early Delivery” delivery request has been approved.
- Hardware delivery: Each component serial number is documented and stored in the PA PCP Early Delivery SharePoint site.
- Software has been uploaded to the “PA PCP Early Delivery” site.
Release stage definitions
The figure below illustrates the progression of the various release stages throughout the project lifecycle, as well as the alignment between these stages and corresponding test phases. This defines the criteria for each release stage. However, it is allowed to fulfill release stage criteria in an earlier stage or in a combined release stage, which can be the case for products not part of a system and those developed in a fully agile environment. If a product is released without going through the stages separately, all applicable release stage criteria must still be fulfilled before release.
Each of the release stages is subject to the configuration change control process. Any changes made to a version, such as a defect corrections or functionality improvements, must be handled in accordance with this process.