Table Of Contents

Versioning Related Packages

Last Modified: November 6, 2020

  • Try to only depend on Runtime-visible packages or Products. Only depend on nonvisible packages as a last resort. Most nonvisible packages are components of a larger, visible package which should be referenced, because visible packages are easier to manage on the deployed system in NI Package Manager. Depending on a visible package ensures that all required components are present.
  • Declare all dependencies with a minimum required version constraint (">="). Only change the minimum version if you know those versions work.
  • Packages have OS support requirements. NI recommends that you only depend on packages that match your package's OS support.
  • Only declare Recommends or Suggests relationships on non-hidden packages (in the package selection dialog for NI Package Manager, the default is to not show hidden packages).
  • Avoid circular dependencies. They are installable but can create difficult upgrade scenarios and may prevent the packages in question from being updated independently. If you are tempted to create a circular dependency, instead combine the packages into one.
  • Do not declare relationships on the same package that are incompatible—the package will not be installable. For example, do not have Package A 1.0 depend on Package B 2.0 when Package B 2.0 depends on Package A 2.0. Package A 1.0 will not be installable, because Package B’s requirement that Package A 2.0 be installed cannot be satisfied.
  • The package version typically contains four numeric fields separated by period characters: Major.Minor.Patch.Build. Use the following guidance for specifying an initial package version and a scheme for incrementing it:
    • Major – Indicates a major change in the package. For example, significant new features were added.
    • Minor – Indicates a minor change in the package. For example, incremental adjustments to existing features.
    • Patch – Indicates only bug fixes or minor tweaks, but no other functional changes.
    • Build – Used to distinguish different builds of the package from each other during development, before the package is released. The build number is not shown by default in NI Package Manager, so it does not signify anything to the user.

Only one package with the same major, minor, and patch number combination should be released to users.

It is recommended that at the beginning of development for your release, you update the package version’s major, minor, and patch numbers using the guidance above. Then set the package’s Version field to increment property to Build (4th field), which will automatically increment the build number with each build of the package.


Recently Viewed Topics