This document describes the technical steps to create a new release of VOLTHA.
Creating the initial release¶
A release branch name is decided on, where all tagged releases will be created
in each repo. Historically this has been
voltha followed by the Major and
Minor Semver version, such as
voltha-2.3, etc. The rest of this section will use the
release as an example:
A branch named
voltha-2.3 is created on the voltha-helm-charts repo.
Release candidates will be created of each chart for the
The action that indicates the creation of the
2.3 release is to changing
helm chart, and adapter charts with version:
2.3.0 specified in
Chart.yaml within the voltha-helm-charts repo.
Accompanying tests for 2.3 are created by creating a branch created named
voltha-2.3 on the voltha-system-tests
repo. At release we create a tag
2.3.0 on that branch.
These two repos are the only ones receiving a
2.3.0 tag. Other repos that
contain individual components have their own versioning/release cadence, driven
For all other repos that create components that go into the release, tags will
be created and
voltha-2.3 branches are created starting from the tag.
To allow for future patches to go into the repo in a way that does not conflict
with the patch version, each component repo’s
VERSION file should have it’s
Minor version increased. (ex:
1.2.0-dev, so future
component release can easily be created).
Testing CI jobs will be created that check out the voltha-2.3 branch of the
repo, testing the charts as checked out with the
voltha-2.3 branch of
voltha-helm-charts. Patches on the
voltha-2.3 branch of components
that build containers will need to be changed to rebuild those containers and
test with the
voltha-2.3 branch of helm charts.
Creating point releases on a stable branch¶
If a fix is only needed to the helm charts:
Make the fix on the master branch of voltha-helm-charts (assuming that it is required in both places).
After the master tests pass, manually cherry-pick the fix to the voltha-2.3 branch (the Chart.yaml version would be different, requiring the manual step).
Cherry-picked patchsets on that branch will be checked by the voltha-2.3 branch of tests.
When it passes, submitting the change will make a new 2.3.x release
If a fix is needed to the components/containers that are included by the helm charts:
Develop a fix to the issue on the master branch, get it approved after passing master tests.
Manually cherry-pick to the voltha-2.3 branch of the component, incrementing the patch version, and test with the voltha-2.3 version of voltha-system-tests and helm charts.
Update helm charts and go through the helm chart update process above.
What changes can be brought into a stable branch?¶
For a change to be suitable for a stable branch, it has to be either a:
Non-code fix (documentation, build process)
Security or compatibility updates (problem found in a dependency, upstream software EOL, etc.)
Process to create a change on a stable branch
Create a jira ticket for the problem and document the
Affects Version/s:- field with affected version(s)
Discuss and get consensus on the issue via the Voltha mailing list, in the all-Voltha meeting, or on Slack about whether this fix should be brought to a stable branch
Create a fix, and go through the integration process to create a new point release.
What is a bug?¶
Anything that causes a functional regression test (Robot tests) to fail
Not a new feature!
Severe issue (causes data loss or crash), or frequently occurring are generally more likely to be accepted.
Issues that are merely annoying and don’t cause data loss or a crash, or happen very infrequently or can’t be reproduced may not be.
As a best practice, please add tests when bugs are found, if tests don’t currently cover the particular bug. Examples:
Robot tests for integration-related issues
Unit tests for code-level issues
API Deprecation policy¶
VOLTHA supports 2 release deprecation policy. Starting from
the APIs that are marked as deprecated are automatically removed.
For example an API marked as deprecated in
voltha-2.9 will be removed after
voltha-2.10 release and will not be present anymore in
The removal process is intended to happen automatically, meaning no further notice of removal needs to be sent out.
The deprecated objects and APIs are marked in the voltha-protos using the
deprecated construct from protobuf, as per specification.
An example is
int32 old_field = 6 [deprecated = true];
Repos (lazily) branched for each release¶
bbsim (also creates containers)
Components (which build containers)¶
voltha-onos (includes ONOS Apps)