- VI Package Manager
-
Idéer
+8
Under vurdering
Implement "Install for previous LabVIEW version"
We often have enquiries from our customers to make available a version of our toolsets for an earlier version of LabVIEW than the VIP was developed for. We don't want to develop all our toolsets with LV 7.1 for instance, just to make certain all our users are covered, and it's a huge task to down-save all our toolsets and make new VIPs for those versions. The user also has a hard time doing this, as a simple "Save for Previous Version" doesn't cut it, as the user has to manually recreate the palette in the process (which many users don't know how to do).
VIPM currently allows the user to install for the LV version that the package was developed for, and for later versions as well if we have configured the package to allow this. VIPM uses Mass Compile for this (unless the user has disabled Mass Compile in VIPM of course). I suggest one of two changes:
1) Either allow the end-user to install a package for an earlier version of LabVIEW than the package was built for. This requires the user to have installed the lowest LV version that the downloaded package demands, as well as having installed the target LV version as well. Then VIPM could use the "Save for Previous..." method and re-create the palette for the user.
2) Or, allow the VIP-developer to build packages for earlier versions of LV than the VIs are developed for. This poses the same requirements on the developer, having both the source and target LV versions installed, and would enable VIPB to use "Save for Previous..." when building the packages.
I prefer 2), as that basically automates the process I'd otherwise go through to make our VIPs available for earlier versions of LV, but without me having to handle duplicate build scripts for VIPB. And it puts fewer requirements on our end users.
Best regards,
Steen, GPower
VIPM currently allows the user to install for the LV version that the package was developed for, and for later versions as well if we have configured the package to allow this. VIPM uses Mass Compile for this (unless the user has disabled Mass Compile in VIPM of course). I suggest one of two changes:
1) Either allow the end-user to install a package for an earlier version of LabVIEW than the package was built for. This requires the user to have installed the lowest LV version that the downloaded package demands, as well as having installed the target LV version as well. Then VIPM could use the "Save for Previous..." method and re-create the palette for the user.
2) Or, allow the VIP-developer to build packages for earlier versions of LV than the VIs are developed for. This poses the same requirements on the developer, having both the source and target LV versions installed, and would enable VIPB to use "Save for Previous..." when building the packages.
I prefer 2), as that basically automates the process I'd otherwise go through to make our VIPs available for earlier versions of LV, but without me having to handle duplicate build scripts for VIPB. And it puts fewer requirements on our end users.
Best regards,
Steen, GPower
Kundesupport af UserEcho
My use case was when I was developing a reuse library in 2011, but it was decreed that the library should be in 2009. I wrote my own VI to save for previous that I ran before performing the package build.
I have made such a VI for backsaving several times as well, and it has to take into account that you don't want to drag with you anything from Program Files (user.lib, vi.lib etc.), it has to make sure that you end up in the proper directory for package building and such. It seems I have to take a new thing or two into account each time I do this "backsaving" VI, and/or I end up patching something anyway after that VI has run.
If such a feature was available in VIPM itself we wouldn't have to make these tools ourselves (obviously :-)).
/Steen
There are many things that can go wrong with Save As. It's not clean cut. Solving this problem on the package install side would be very difficult. Even on the development side. You need to do testing to make sure the new source actually works. If the down-save from VIPM fails even once, then nobody would use it. It won't be trusted and that's wasted development.
Are you spending a lot of time saving for previous? Then perhaps you should just develop in that version. I think right now, it's common to develop in LV2009. That's a recommended starting point for most tools. If your tool has some special LabVIEW version specific features then it can't be down-saved anyway.
This is a fair request. It's just impossible to get it working to the point which people would actually use it. Besides, some forethought in developing the tool and some education on the customer's side to upgrade LabVIEW doesn't hurt.
We have to distribute to universities with many running slightly older versions (2014-2015) than the one we develop with (2016), so the risk of down-saving is very small. We would prefer VIPM handling this for us.