Skip to content

Release Process

Jump to bottom
Joel Dixon edited this page May 2, 2024 · 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/MeasurementLink Generator.vipb, MeasurementLink Service.vipb, MeasurementLink Examples.vipb, and MeasurementLink.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.
  • It is also necessary to manually update the version in Build Specs/MeasurementLink Generator.vipb, MeasurementLink Service.vipb, MeasurementLink Examples.vipb, and MeasurementLink.vipb before publishing each pre-release or release.

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

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/MeasurementLink Generator.vipb and MeasurementLink Service.vipb locally and add the built .vip files to the assets (ni_measurementlink_generator-.vip and ni_measurementlink_service-.vip).
    • 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.
    • Zip up the Example Measurements directory contents and add it to the assets as 'measurementlink-labview-examples-.zip'.
  • 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