Release Process

1. Determine release version

We're generally following the standard semantic versioning scheme for grpc-device releases, where the version of the release will be whatever version main branch shows. Once the release has been made published, main will be bumped up to a newer version. 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 vX.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 vX+1.0.0

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.

2. If there are in-flight PR's, inquire respective developers if they'd like to push their changes to the release.

3. Create release branch

Before ni-central branches for release, follow this link then click on "New branch" to create a branch titled releases/x.y.

Automated Draft Release

Whenever a releases/X.Y branch is updated (either created or merged into/cherry picked to) the CI will run, which when finished will 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.

4. Bump versions in AzDO

4.1. Before ni-central branches for release

Follow this PR to update the main branch to pull in ni-grpc-device-release-desktop. We will make a change after branching to switch back to *main-desktop, but this way we do not need to submit a direct change into the ni-central release branch.

4.2 After ni-central branches for release

• Update version.yml on AzDo. Follow this PR for reference.
• After step 5 is completed, revert the change from the PR in 4.1 to switch back to pulling in ni-grpc-device-main-desktop and bump versions to the next release. Run update-depslock after dependencies.yml has been updated.

5. Update CMakeLists.txt on GitHub

Follow this PR for reference.

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.

7. Publish draft release that was generated

Follow previous releases for reference. 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. When writing the "Updates since..." section, the current protocol is to check the list of PRs(these can be seen in the generated draft release) that went into the release and ping their authors for any high-level contributions worth being included.
• "Minor Breaking Changes:" are PRs labeled source-breaking, found here. Please check that these changes were completed for the release.
• "Major Breaking Changes:" are PRs labeled binary-breaking, found here. As before, please check that these changes were completed for the release.
• Along with the generated content, we also attach the "Driver Version Support" table at the bottom. Edit the previous release's notes, which will allow you to copy+paste the table to your release draft, and change necessary contents in the release draft.
• 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)

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 vX.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.