First, let me state I think VIPM is a fantastic tool and I applaude the folks at JKI for creating it and making a community version available to users. Still, the inability to have multiple versions of the same package installed side-by-side is eventually going to cause people to encounter the Labview developer's equivalent of dll hell. I can easily see situations arise where a developer needs to integrate two components, but one component relies on PublicReuseCodeLibrary version 1 and the other relies on an incompatible PublicReuseCodeLibrary version 2. That's going to be a tough situation when only one of them can be installed on the system at a time.For my personal packages I started appending a version suffix to the package file name. It has worked reasonably well for me so far, but of course it looks a little odd having multiple listings of the same package in VIPM. Does NI have a recommended set of best practices to avoid VI Package Hell?

Developer Center Discussions

Avoiding 'vip hell' with VIPM packages

I agree that there is room for different solutions.

The community has been successful with backward-compatible API upgrades. This discussion thread identifies downsides of this approach, from both API developer and API user perspectives.

I recently learned about yet another approach for version-specific yet backward-compatible behavior. niWLANA Open Session VI (from the NI LabVIEW WLAN Analysis Toolkit) has a toolkit compatibility version input. To paraphrase help file, if you have toolkit version 3.0.0, you can open a session with toolkit compatibility version set to 2.0.0, and the API will exhibit version 2.0.0 behavior. This allows the user to upgrade and maintain prior functional behavior; new features from later releases are unavailable. Note that in this model you can have both behaviors in parallel, in different sessions...

With regard to "standard" SxS installation, this discussion focused on library names, with some references to palettes. I would expect "standard" SxS libraries to come with separate help files and separate installers. If a library has custom errors, we would also need to address custom errors files. Can you think of any other deliverables associated with APIs?

Kosta