[!WARNING]
Before starting the release process make sure that you have discussed with the owning team several weeks before needing a release as to align with already planned cycle release scheduling or if needing an off cycle release. This also makes sure that there is planned guidance to walk through the process if issues arise.

1. Determine release version

We're following the standard semantic versioning scheme for grpc-device releases, where the release version is what's shown in main branch. Once the release has been 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 changes. A binary compatible changes is any update to proto files such that pre-existing clients will continue to work when the server is updated.
   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. These PRs will be labeled with 'breaking-change'.
   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, ask respective developers if they'd like to merge their changes before the release branch is created.

3. Create release branch

Before ni-central branches for release, follow this link, click on "New branch", then title it 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. 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:

• Our automated draft release assumes it's a patch release, But if this is a Major or Minor release, update the title, tag, and version comparisons accordingly.
• Fill out the "Updates since..." and "Breaking Changes" sections. When filling out the "Updates since..." section, check the list of PRs(seen in the generated draft release) that went into the release and ping their authors for any high-level contributions this release worth being included.
• "Minor Breaking Changes:" are PRs labeled source-breaking, found here. Please check that these changes were completed for this release.
• "Major Breaking Changes:" are PRs labeled binary-breaking, found here. As before, please check that these changes were completed for this release.
• Along with the generated content, we also attach the "Driver Version Support" table at the bottom. Edit grpc-device's README.md, which will allow you to copy&paste the table to your draft release.
• Do any manual testing you want to do with the Assets to validate bug fixes and new features.
• Get the draft release peer-reviewed by someone to make sure everything looks good.
• Publish the release. (congrats!🎆)

5a. Bump version on AzDO

[!Warning] Before bumping the version in azdo make sure the github actions started by the release branch has finished and the azdo pipelines have created final builds.

Follow this PR for reference.

5b. Bump version on GitHub

After step 4a is completed, Follow this PR for reference.

6. Update gprc-device installer to reference latest version

Update grpc_device_installer to reference latest grpc-device exports.

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.