CompatabilityVersion in control file

[ShockHouse]

How is the CompatabilityVersion generated, and is there a programmatic way to get it through the nipkg CLI?

Example when using NI Package Manager 21.3

nipkg show-version = nipkg 21.3.0f103

CompatabilityVersion = 210300

Example when using NI Package Manager 2023 Q1

nipkg show-version = nipkg 23.0.0f123

CompatabilityVersion = 230000

In some of our cases we can't upgrade NI Package Manager to a newer version, and changing the compatibility version to an older version than what the package was built with will allow it to install on older versions. The only scenario I've found is to just put 210300, but I was wondering if there is a more programmatic way to get that. Of if it's as simple as the compatabilityversion always being the 23.0.0f123 -> First Numbers, Second numbers padded %2d, last numbers %2d before the f.

[Scott_Richardson · Accepted solution]

NI Package Manager's nipkg.exe and "package builder" applications like LabVIEW use a client library to create packages. That library defines the compatibility version, which typically is equal to NIPM's version as you indicated in your post.

When NIPM packs a package, if the input control file to the pack operation does not include a "CompatibilityVersion" attribute value, NIPM will add a value equal to its compatibility value. If the control file already contains the attribute, it persists that input value into the control file in the package.

FWIW, there are two primary reasons that NIPM typically increments its compatibility version with every release:

1. NIPM maintains a list of default "NI Path" values, and new values are generated for the first release of a new product, and every new side-by-side version of an existing product. If an older NIPM attempted to install a product that had a newer "NI Path", the older NIPM would not know where to install it. That is the current design of NIPM.
2. If NIPM adds a feature that older NIPM versions do not know about, if that feature is used in a package built by the newer NIPM, the older NIPM would not know how to honor settings for that feature. 

[ShockHouse]

Which makes sense, you can't always ensure that a new package doesn't have a breaking change with an old version of NIPM. It just presents issues when we develop a program that consists of packages X, Y, Z and a customer updates X but is using a newer version of NIPM on their machine than us. This forces us to have to update, which in turn forces all our other customers to have to update. This becomes a pain with offline systems, and heavily managed systems where it's not as trivial as just updating.

So we have a tool that takes our packages and attempts to install them, and downgrades them if needed based on the CompVers and the currently installed version (unpack -> change version -> pack). I just needed a way to compare the packages CompVersion with the current NIPM install, which was the reason for my question.

I can understand this would run into situations it won't work. But most of our packages are built from LabVIEW, or NIPB with PPL's and *.seq files using the Program Files or Program Data paths. So they are pretty seamless to just make them appear older than they are, and then install them. But a useful feature would be for NIPM to detect what paths are being used so when something gets packed, it can get packed with old CompVersions if that's all that's needed.

[Scott_Richardson]

Thanks for sharing how the compatibility version incrementing is impacting your internal workflows. I'm glad that the pack and repack tool is allowing you to mitigate the issue, although not ideal. We will continue to explore options to potential improve in the future.