Best practice for backward compatibility of reuse libraries?

[OneOfTheDans]

At work we pick a version of LabVIEW and use it across the board until we eventually upgrade everything.

Now I'm hoping to develop some open source hobby libraries to share with the community. I plan to distribute a VIPM package. I want to use the freshest version of LabVIEW (23Q1) because I have the Community Edition so why not see the improvements from a few years of NI's effort.

Is there any simple or at least standard process for developing in the latest LabVIEW version but allowing folks on older versions to still run the code? I don't want to lock out most other users who aren't on the "bleeding edge".

[Kevin_Price]

I'd recommend the opposite.  Use the oldest version you can that will support your functionality.   Even if all you have is 2023, when ready to put together a VIPM package, first do a "Save for Previous Version..." back several years into a new folder.   If you used a feature or function not available in that version, you'll get a warning.  Then you can decide whether to recode to avoid the incompatibility or whether to be a little less retro in your back-save.

Then make your VIPM package out of the code in the back-saved folder to minimize the # of users you lock out.

-Kevin P

[OneOfTheDans]

Thanks, I was hoping that wasn't the case. We use LV20SP1 at work so I was looking forward to trying something newer at home.

For the back-saving option, do I need the earlier LabVIEW version installed to Save As? Or for VIPM to package it?

[IlluminatedG · Accepted solution]

You'll need the version you want to save packages for. 2020 is the base year I've been using for packages. Interfaces & the new collection types from 2019. There aren't any significant language features new in 21-23 and in fact you might find some of the changes annoying if you've been using LabVIEW for any amount of time (they changed the wire routing algorithms and some other stuff) though of course some stuff got fixed too. VIPM needs the version of the package build since it does some relinking and dependency management for VIs and controls since they'll be in a different location after install.

2020 CE is available for download. If you want to do development in 23 you would need to do the save for previous from 23 (don't need 20 for that) but then to build the 2020 VIP you'd need a 20 environment. And then if you have other packages that depend on that package... make sure you have that package installed for both versions of LabVIEW, back save again, and make sure everything links properly in 20... Which is why you'll just want to work in 20. It's not really feasible to continually be back-saving for package building and maintaining package installs and updates in multiple versions.

[OneOfTheDans]

Thanks guys, 2020 it is then!

I'm glad I setup everything in a virtual machine, it should be pretty quick to clone and setup a fresh OS. I don't like mixing LabVIEW versions on one "machine" - I have enough troubles in life ready 😄

---

@IlluminatedG wrote:

There aren't any significant language features new in 21-23

---

lol I didn't want to be the one to say it!

[IlluminatedG]

FWIW I just got done installing 2020 after installing 2022 myself (both Community Editions) and there haven't been any issues I've run into yet that weren't of my own doing 🙂 Though there's been a couple of times I've thought I was in 2020 and was working on something in 2022 instead, that's the main issue I see. I do need 2022 for some stuff for a specific bugfix so I do want them side by side.

[billko]

I have a taskbar icon for each explicit version of LabVIEW, and I always open up the version of LabVIEW that I want from there.  That's the only way I can see to keep them separate.

[IlluminatedG]

Ditto. But the numbers are practically illegible, at least on Win 11, and aren't otherwise differentiated anymore. I'm so used to working from file explorer with tortoisegit and all though that I'm continually opening in the wrong version.

Is there a way to force LV to a specific version when double-clicking from explorer? Can't say I'm a fan of the smart behavior now that I finally have a system with multiple versions at once. I'd like to be able to set 2020 to the always opened with default and I can manually open in 22/23 when needed. Worst case with that I get told file version is too new. Worst case with the current smartness is I accidentally version bump everything and hope I didn't have any changes not in SCC yet and have to do some save for previous juggling.

[santo_13]

I recollect someone on the forum developed a launcher app that allows you to select the LV version to launch.

I guess @paul_cardinale developed it.