Releasing Carbonite

Two types of releases are performed:

  • Sprint releases, which are made at the end of each 2-week long sprint

  • Patch releases, which can be made at any time and include only fixes for a previous release

For every release, a git tag of the form v{version-number} is created on the appropriate commit. This will trigger an automatic promotion of the build artifacts previously published from that commit into “officially versioned” artifacts. For example, if the commit SHA started with baadf00d the originally published artifact would include this information, along with branch name and CI system used to make the artifact. After the tag has been made the version will simply be the {version-number} specified in the git tag. This creates a clear distinction between in-development builds and official releases. Official releases are the only artifacts that will have the short form version (no hash, no build number, etc). Please understand that all that information is still available inside the artifact, if needed.

Sprint releases are always made from the default branch (main/master). These releases will never have a patch number set, they will end with a .0.

Patch releases are made to deliver bug fixes. They must always have a patch number. A patch to the latest release can be delivered from the default branch if only bug fixes have been added to that branch. Otherwise a branch must be created from the version tag which was originally created for the release that needs fixing. This branch should be named patch/{version}. Note that you do not include the patch number in the {version} used to name the branch. This allows us to release multiple successive patches to the same sprint release from that branch. Each patch release will increment the patch number and have an associated git tag that includes the full version number (including patch number).

Carbonite follows a romantic versioning scheme (in contrast to a semantic versioning scheme). It is inspired by the NVIDIA GPU driver and is one-hundred based. We will only use the patch number (fractional in this scheme) for patching, so every sprint release we will bump the 100-based number. This means that officially released artifacts from sprint release will take the form of h.0 (where h is a number between 100 and 999) while officially released artifacts from a patch release will take the form of h.n where n > 0. Every sprint release will increment h by one. We envision moving Carbonite to semantic versioning in the future, once we have fully converted to Omniverse Native Interfaces.

Once a release has been made, the version number in VERSION file must be increased if further development is planned on that branch. If the next release is a sprint release then the hundred-based number is simply incremented by one. If patch number was set, it is removed. On a patch branch, the patch number is incremented by one. Note that incrementing on a patch branch post release is only needed if further patches are planned.

You will have noticed in the previous paragraph that there was a mention of the possibility that the patch number was set on the default branch. You may be wondering how that is possible. The scenario is as follows. The development team hasn’t submitted any new feature work in the default branch, only bug fixes. A request comes in to urgently patch the latest sprint release with these bug fixes. In that case it makes the most sense to deploy the patch from the default branch by simply adjusting the VERSION file to match. That being said, if there is a strict requirement from customers to only include a single bug fix and no other bug fixes this would not work and we would follow the regular flow. That is, we would create a patch branch from the release tag, set the VERSION for a patch release and cherry-pick the fix to that branch.

Note

The above applies to CHANGES.md as well. The the next release version is used as the heading of a new section at the top of the file immediately after a release. The top section in CHANGES.md must always have the same version number as in VERSION. Once we have the capability to automatically generate release notes (from MR/commit messages) the version number in VERSION will become the single source of truth.