Release Process

The Intel® Clear Containers project follows the semantic versioning and will have a release each Friday.

Versions are in the form MAJOR.MINOR.PATCH, examples are: 2.1.1, 2.1.0-rc.5, or 99.123.77+foo.bar.baz.5.

• When PATCH increases, the new release contains important security fixes and an upgrade is recommended.
• When MINOR increases, the new release added new features without changing the existing behavior.
• When MAJOR increases, the new release added new features, bug fixes, or both which change the behavior from the previous release.

PATCH can contain extra details after the number. Dashes denote pre-release versions. 2.1.0-rc.5 in the example denotes the fifth release candidate for release 2.1.0. Plus signs denote other details. In our example, +foo.bar.baz.5 is additional information regarding release 99.123.77.

MAJOR releases will likely require a change of the container manager version used, for example Docker*. Please refer to the release notes for further details on this regard.

Release checklist

To always have a stable and fully functional version of Intel® Clear Containers working on all supported distributions, ensure the following automatic and manual tasks are performed:

1. A new issue to handle tracking the new release will be filed
   • The issue description must contain the Release process task list
2. The HEAD commit of the master branch will be tested using the tests included in the source code within the tests/ directory.
   • HEAD must not contain any medium or high impact issues as reported by coverity.
3. Once the tests pass, same commit used in step 1 will be tagged and released as a release candidate. Otherwise, a new issue will be filed in the cc-oci-runtime issue tracker on GitHub*.
   • versions.txt must be updated with package versions used by the release.
4. The new OBS packages will be generated using latest public release candidate.
5. Tests will run for each OBS package.
   • Manual tests
     • Installation test.
     • Package signature test.
   • Automated tests
     • Integration tests included in the source code under the tests/integration directory.
6. When the tests pass, the same commit will be tagged and used to release the stable version. Otherwise, a new issue is filed and reported to the maintainers or the release manager.
7. Release notes must be provided on GitHub. The release notes must document:
   • A brief summary of known issues, pointing to the appropriate Issues/PRs.
   • The version or versions of Docker supported by the release.
   • The version of Clear Container image used by the release.
   • The installation instructions link.
   • Any common vulnerabilities and exposures (CVEs) fixed with links to the CVE database.
8. Release details will be posted to the public mailing list.
9. Public IRC channel will be updated with a link to the latest release.