Skip to content

Release Process

Jump to bottom
Joel Dixon edited this page Jan 3, 2025 · 12 revisions

Branching

Active development for the next release occurs on the main branch.

During finalization, we create a release branch (e.g. releases/1.2) in order to control which changes target the imminent release vs. the next release after that. Changes that are intended for both the imminent release and subsequent releases should be made in the main branch and cherry-picked into the release branch. Changes that only apply to the imminent release (such as version numbers) may be made directly in the release branch.

Versioning

  • This project uses semantic versioning. Compatibility breakage should be rare and should be accompanied by incrementing the major version.
    • This does not apply to examples or code that ships with the examples.
  • After creating a new release branch, update Build Specs/Measurement Plug-In SDK Generator.vipb, Measurement Plug-In SDK Service.vipb, Measurement Plug-In SDK Examples.vipb, and Measurement Plug-In SDK.vipb in the main branch to have the next pre-release version number. For example, after creating releases/1.2, update the build specs to specify version = "1.3.0.1". This reduces confusion about which branch is which and prevents packages with the same version being built from different branches.
  • With this version in main, when the next release branch is created, it will likely already have the correct version. If you then create the releases/1.3 branch, for example, the .vipb versions will already be '1.3.0.1' and be ready to make the release.
  • The versions in the release branch should match the versions of the packages in the branch at the time of release. So if you want to make a subsequent release with 1.3.0.2, you should first bump the package version numbers to 1.3.0.2, submit that PR to the releases\1.3 branch and then build the VI packages from the branch.

Tagging

Git tags for pre-releases and releases are version numbers in the form v1.2.0.2.

Publishing

This GitHub repository has a mostly manual workflow for publishing a release with its packages.

Creating a new release on GitHub

Prerequisites

  • You need to have these drivers installed to build the packages. You should use the previous quarterly release.
    • NI-DCPower
    • NI-FGEN
    • NI-DMM
    • NI-Scope
    • NI-Digital
    • NI-VISA

This publishing workflow is initiated by manually creating a new release in the GitHub web UI:

  • On the releases page, click Draft a new release.
  • Create a tag for the new release, based on the desired version number.
  • Choose the appropriate target branch for the new release:
    • Early pre-releases should be released from main.
    • Late pre-release and official releases should be released from a release branch such as releases/1.2.
  • If this is a pre-release, check Set as a pre-release. If this is an official release, uncheck Set as a pre-release and check Set as the latest release.
  • Click Generate release notes and edit the generated release notes for brevity and style.
  • Click Save draft. Consider sharing the link to the draft release with the other repo maintainers.
  • Add packages and assets to the release.
    • Build Build Specs/Measurement Plug-In SDK Service.vipb, Measurement Plug-In SDK Generator.vipb, Measurement Plug-In SDK Examples.vipb, and Measurement Plug-In SDK.vipb locally and add the built .vip files to the assets (ni_Measurement Plug-In SDK_generator-.vip and ni_Measurement Plug-In SDK_service-.vip etc).
      • NOTE: These can take several minutes to build, especially the Measurement Plug-In SDK Service.vipb
      • Build these .vipb files with 'LabVIEW 2021' selected in VI Package Manager
      • Build Measurement Plug-In SDK Service.vipb first. Install it into your LabVIEW 2021 instance after building. This is needed for building the generator package.
      • Also ensure the correct version of NI gRPC Types (ni_protobuf_types-1.x.x.x.vip) is installed.
      • Build Measurement Plug-In SDK Generator.vipb, Measurement Plug-In SDK Examples.vipb, and Measurement Plug-In SDK.vipb next. You don't need to install these after building.
    • Add the appropriate version of ni_protobuf_types-x.x.x.x.vip to the assets.
    • Add the appropriate version of ni_lib_labview_grpc_library-x.x.x.x.vip and ni_lib_labview_grpc_server-x.x.x.x.vip to the assets.
  • Once the versions, assets, and release notes are ready, click Publish release.

Publishing packages to vipm.io

This publishing workflow is a manual process initiated on the vipm.io website. Using an account that claims ownership of said packages. Currently these packages are owned by Kiran Sreekantham.

Visit each link and click "Upload New Release". Follow instructions.

Cherry-Picking

To cherry-pick a change into a release branch:

  • Make sure the PR submitting the change to the main branch is completed.
  • Check out the target release branch and create a dev branch.
  • Run git log main and find the commit id for the merged PR (not your dev branch commit id).
  • Run git cherry-pick -x <commit-id>. If there are conflicts, resolve them and re-test.
    • -x includes (cherry picked from commit <commit-id>) in the commit description.
  • Push the dev branch to GitHub and create a PR.
    • Prefix the title with [releases/N.N] where N.N is the release branch version.
    • Include a link to the original PR in the description.
Clone this wiki locally