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