VI Migration Independent of LabVIEW Version

[CMal]

With the increasing size of the LabVIEW ecosystem, there is a growing number of third party tools written in LabVIEW that are versioned independently from LabVIEW's version number.  For example, I could create an API that has versions 1.0, 2.0, and 3.0, and all three versions could be compatible with LabVIEW 2009 or later.  Tools like VI Package Manager make it easy for content creators to publish multiple versions of an API, and for users to upgrade and downgrade between those versions.  However, this ease of use disappears if significant changes have been made to the VIs in an API, such as:

• Changing VI connector panes
• Renaming or moving VIs on disk
• Adding VIs to a library

If any of the above changes are made to VIs in an API between versions, it can become impossible to migrate code between the two versions without a lot of manual searching, replacing, and relinking.

LabVIEW should provide a mechanism to define mappings between old and new versions of third party toolkit VIs.  Consider the case where I make the following changes to a VI from my toolkit:

	Version 1.0	Version 2.0
VI Path	<userlib>\mytoolkit\CompRes.vi	<vilib>\mytoolkit\Compute Result.vi
Owning Library	none	Mytoolkit.lvlib
Connector Pane

I should be able to create a mapping file included with version 2.0 of the toolkit that describes the changes made between versions 1.0 and 2.0 of the VI.  This way someone could write an application that calls version 1.0 of the VI, then upgrade their toolkit to version 2.0, and the application source code would be able to find, load, and relink version 2.0 of the VI without any hassle.

[AristosQueue (NI)]

Some of us who write G code libraries have discussed this. Even within NI, we don't have a good solution for the problem. I'll give this my kudos!

I should mention that whenever this comes up, someone always responds with, "But what you should be doing is publishing APIs that don't break backward compatibility and just add new features as new functions." I won't argue the pros/cons of that kind of backward support. That's an endless argument. But even if you have that backward-supporting API, there are still times when a client would want to update to the new API, and having a built in tool that could, on demand, remap a VI hierarchy to call a new library, would still be valuable. The tech involved in creating the muation is valuable regardless of whether we go for auto apply or apply on demand. Those are totally different questions.

[JackDunaway]

Custom API mutation rules? Brilliant -- sign me up.

Your example is fantastic, illustrating three common mutations -- a Conpane change, a filename change, and a library change.

[CMal]

Thanks, Aristos.  I have also heard the argument for creating "compatabilty libraries" where both the old and new functionality is included in the new library.  Sometimes that argument is valid, like when the new version contains functionality that might be undesireable to users of the old version.  But in that case there really isn't any point in upgrading to the new version if the versioning is independent from that of LabVIEW.

[JÞB]

Wow,

That con pane has gotten a bit dated hasn't it?  Probably time to get back to the basics and define a better means of transfering data between wires and nodes that are terminals. 

(Did I just say that?)  I guess I did. 

Count my Kudos for "VI Instance Con Panes" 

(I won't see that in 201x I'm sure but......before LabVIEW is used to calculate and transfer my pension checks would be nice)

Your "map" has a few other potentials

[AristosQueue (NI)]

I also want to say that I have raised this topic with developers I know of other programming languages. I always get this blank stare and a question: "Why would you trust the guy who developed the API to update your code?" For a lot of these folks, they seem to have the opinion if an API makes a change that breaks compatibility, there's too high a probability that the automatic mutation to the new API isn't actually the right thing to do for caller code... the caller code needs human inspection to be updated. LV users have the opposite expectation brought on by years of us auto-updating for mutations. There are cases where we have gotten it wrong, but those are really rare, and the cases where we have improved systems substantially without requiring work by users to update to the new API are significant. My point here is that while we think it is valuable, there are not many tools out in the world that we can look at as models for this sort of mutation specification.

[CMal]

---

@AristosQueue (NI) wrote:

My point here is that while we think it is valuable, there are not many tools out in the world that we can look at as models for this sort of mutation specification.

---

I think this makes sense in LabVIEW while it might not make sense in other languages because the LabVIEW language and development environment are tightly coupled.  Any LabVIEW code must be written in the dev environment, which means I always know that environment is available to perform code mutations for me.  In pretty much any other language, if I write a reusable API I have no idea what sort of dev environment clients of that API will be using.  This makes it impossible in a lot of languages to do this automatic migration at all.

[AristosQueue (NI)]

> This makes it impossible in a lot of languages to do this automatic migration at all.

I strongly disagree... modifying the text languages is lots easier. You only care about the language, which is generally a text file. You don't care about the IDE... lots of developers will write all sorts of custom grep/sed/awk/python/etc scripts to mutate all calls to a particular function. And there are third party tools to do it. So why not a tool distributed with the library that already knows what to do? After the text is modified, whatever IDE you're using can still load the text. Any sort of mutation can be done completely stand-alone from the IDE-of-choice.

No, as far as I can tell, the barrier is entirely reluctance on the part of the developers involved, both the API creators and the API users.

[SteenSchmidt]

Such migrations would be possible to do already with scripting of course, so the API-developer could offer a migration tool today for the end user to run manually.

Just thinking aloud here;

If there was a place in the LabVIEW IDE to specify plugins that'd run on a number of IDE events (On_subVI_drop, On_object_rightclick, On_whatever...), one of such could be a plugin that ran whenever a changed* dependency was loaded (On_dependency_migrated?). In such a parallel world this idea could be about being able to temporarily overload or extend that plugin within your API installer (VIP, MSI etc.). Not dissimilar to the project provider framework.

* "Changed" could be for any number of reasons, the exact reason would of course be a parameter to the plugin. Reasons could be 'loaded from unexpected path', 'conpane changed', 'data type changed', 'default value changed', 'icon changed', 'VI revision changed', etc.

/Steen