Table of Contents

Releases

Tagging Releases

Releases will be created from release branches only.

Tag Name before 5.31_Maintenance:

<software major>.<branch number>.<release in branch>

Tag Name since 5.31_Maintenance:

<software major>.<branch number>.<release in branch>(_<release_candidate>)

For instance: 5.32.2_RC3, points to:

Note: Since Branch 5.31_Maintenance buildbot will search the last tag matching <software major>.<branch number>.<release in branch>(_<release_candidate>) and generate filename from this information. It is not needed to add “RCx” in buildbot input.

Release Strategy

We will use CI/CD concepts. With the continuous method of software integration and delivery, we will build, test, and deploy iterative code changes continuously.

Each change submitted to an application, even to release/ and feature/ branches, is built and tested automatically and continuously. These tests ensure the changes pass all tests, guidelines, and code compliance standards we established for our application. (CI)

Continuous Delivery is a step beyond Continuous Integration. Not only is our application built and tested each time a code change is pushed to the codebase, the application is also deployed continuously. But it requires human intervention to manually and strategically trigger the deployment of the changes.

Long term goal: We will delivery Maintenance/Update releases every 2 months. This type of release contains bugfixes and small new features and will increment software patch number (5.30.0 –> 5.30.1) Feature releases will be delivered every 6 month. This type of release will contain new main features (or support new devices) and increment software minor (5.30 –> 5.40)

Important links connected with this topic: