Release Process

Versioning Scheme

We're generally following the standard semantic versioning scheme for grpc-device releases. The tags/releases will be in the form vX.Y.Z, where "v" is the standard prefix for version and X,Y, and Z are non-negative numbers representing the Major, Minor, and Patch version of the release, respectively.

With that in mind for a new release consider the following options to determine which type of release you should make:

1. Bug fixes for a previous release
   1. Patch release and the new version should be vX.Y.Z+1
2. New Features/drivers and/or binary compatible breaking changes. A binary compatible breaking changes are any updates to proto files such that pre-existing clients will still continue to work even if the server is updated. These PRs will be labeled with 'breaking-change'.
   1. Minor Release so the new version will be v.X.Y+1.0
3. Binary-breaking changes. These are any changes to proto files where a pre-existing client will stop working with an updated server. Note that these type of changes should be extremely rare.
   1. Major Release and the new version will be v.X+1.0.0

Creating A Release

Release Branch Creation

1. Bug Fixes?
   1. Cherry pick the commits for the bug fixes to the releases/X.Y branch matching the release you're applying the bug fixes to.
2. New Feature(s) and/or Binary compatible Breaking changes?
   1. Create a new releases/X.Y branch based off main. The X and Y here represent the Major and Minor version of the new release.
3. Binary breaking changes?
   1. Create a new releases/X.0 branch based off main.

Automated Draft Release

Whenever a releases/X.Y branch is updated (either created or merged into/cherry picked to) the CI will run, trigger our create_release workflow, and create a draft release. If you look at the grpc-device releases tab, you'll see the new draft release that will roughly look like this:

It will have all the assets attached from the CI run and also have some of the standard info we include on our releases.

Updating Draft Release

The following are the manual updates you'll need to make to the draft release

• Update the tag and title if necessary. Our automated draft release assumes it's a patch release on the most recent release. But if this is a Major or Minor release, make sure to update the tag and title accordingly.
• Fill out the "Updates since…" and "Breaking Changes" sections. The draft release will include a link to the full changelog between the most recent release and the draft release target commit. You can use this to gather up the PRs that constitute the changes for the release. Note again, that PRs containing breaking changes should have have the 'breaking-changes' label on them.
• Do any manual testing you want to do with the Assets to validate bug fixes and new features.
• Get the release peer-reviewed by someone to make sure everything looks good
• Publish the release

Creating A Release Candidate or Pre-Release

If you're planning to make a pre-release (v1.5.2-rc0 or v1.5.2-prerelease), you can either make a new release from scratch or use the automated draft release as a starting point and update the tag/title accordingly and mark the release pre-release before publishing.

Post Release Action(s)

Update CMake Project Version

Make sure to update the project version in the CMakeLists.txt file in the main branch assuming the next version will be a Minor version bump. So if you just created release vX.Y.Z then assume the next release will be vX.Y+1.0. This adds the version info to the Windows grpc-device server executable. We update main so anyone getting the executable from the main branch knows that it's for an upcoming release vs. the previous one.

The version will be towards the top of the CMakeLists.txt file and look like

project(ni_grpc_device_server
  LANGUAGES C CXX
  VERSION 1.5.2)

For now, this needs to be updated by hand. Hopefully in the future we'll have an automated process to pull this version from a file and bump the file automatically upon a new release being published.

Updating Linux RT Feed

Depending on the type of release and files that have been updated, it may make sense to update the version of grpc-device that Linux RT is pulling in. We have added a Validate Linux RT Feed Package workflow that will be triggered when a new release is made (i.e., when a new v.X.Y.Z tag is added). If it determines any files have changed that warrant bumping the version of grpc-device Linux RT is pulling in an issue will be created in the grpc-device repo. The issue will look like:

To resolve the issue, make the suggested changes in the ni/meta-nilrt repo. You can look at their README for instructions on how to build locally before posting a PR.