Backwards compatibility in VI Package manager

[PeterFoerster]

Hello all,

I recently built my first VI package for distribution and while I absolutely loved the functionality, there's still something I don't quite get about version compatibility:

If I build my VI package with VIPM 2018 I can go back with the LabVIEW version (to 2014 in my case). However, if my customer uses LV 2014, there's a good chance he's not current with VIPM versions, either. There is no backwards compatibility between packages built in newer versions than the end users'.

Searching online I only found out that there's no compatibility between packages built before 2014 and packages built after. What I couldn't find is:

Are the packages generally forward compatible, i.e., could I build in 2015 and support all customers going forward?

Where would I even find a previous version of VIPM?

Maybe I am approaching this all wrong, so: What is the suggested approach for this problem?

Thanks in advance for your help!

[Darren]

I try to stick with VIPM 2014 SP2, that seems to be an old enough version that still supports most VIPM users. I've had trouble trying to install old versions of VIPM in the past as well, I agree that it's not straightforward. I think the LabVIEW 2015 installer includes an installer for VIPM 2014 SP2.

Good luck!

[Jacobson-ni]

Up until very recently we were building all of our DCAF packages in LabVIEW 2014 SP1 with VIPM 2014 (some packages are still on this version). At some point we started using LabVIEW 2015 SP1 but stayed with VIPM 2014 which works but, like you said, you have to have an installation for VIPM 2014.

I have installed these built packages on computers with LabVIEW 2018 with the latest version of VIPM and haven't run into any versioning issues yet.

[Bob_Schor]

I have limited experience building VIPM Packages, but my assumptions were always as follows:

• JKI is very knowledgable about LabVIEW and its Version compatibilities.
• There appears to be an "oldest" Version for installing packages (that is, the Version of the code "inside" the Package.
• If you want a Package to be compatible with, say, LabVIEW 2014 and later, you should not use, for example, VIMs or features that are not available in earlier Versions.
• You should build your Package in the "base" (oldest) Version of LabVIEW your Package will support.
• By assumption, more recent versions of LabVIEW (say, LabVIEW 2018) will be able to open (and save back into VILib) the older version and update it to the new LabVIEW version (just like opening any older LabVIEW version of a VI.

As I hinted above, I haven't tested these assumptions, but have noticed when I use OpenG with a newly-installed LabVIEW Version and save code in the new Version, it also updates the OpenG versions I referenced, suggesting it is re-compiling them for the current Version, so one Version of VIPM can install "older" Packages.  I'm assuming that the Package Repositories don't all get updated (and Version-specific Repositories created) every year.

Would be interested in learning more about how VIPM and Packages (mine and others) and whether I should use the "oldest-practical" version of LabVIEW.  [Since I'm a Channel Wire Enthusiast, that would probably be LabVIEW 2016 ...].

Bob Schor

[PeterFoerster]

Thanks for all the responses! Right now, this issue is not super urgent and it helps to know that I'm not the only one with this problem.