LabVIEW Compatibility Modes

[Dragis]

There have been several ideas proposed to alleviate accidentally savings vis in the wrong version of LabVIEW. While useful, I think the main problem is that LabVIEW doesn't use the information it reads from the file to preserve compatibility. I'd like to propose here that LabVIEW introduce compatibility modes for previous releases in which LabVIEW will break a VI if a feature is introduced that isn't supported by the compatibility version. It will essentially be a built-in, seamless "save for previous" mode. 

By default, LabVIEW will load a VI (hierarchy) in a compatibility mode for whichever version is was saved in. If the user tries to make a change that isn't compatible, LabVIEW will alert the user and the user can tell LabVIEW whether it's ok to save to a newer version that supports the feature.

The level of alerts can be configurable, of course.

Related ideas:

Version-aware LabVIEW launcher

Add header to LabVIEW file to contain the version of LabVIEW

Display VI version in title bar

Version independent Source Code Saves

[Intaris]

I like this idea.

Very much actually.

What about feasability?

[Alex_Pi]

NICE1! would be great for VI-revison, especially for support.

[GregSands]

I was about to post a similar idea, but think this one (which I kudoed a long time ago!) is close enough.  This idea seems even more feasible now that compiled code is very often separate from the VI.

My addition to this suggestion is that when saving a VI (with separate compiled code) for the first time, the default VI version is the earliest one which contains all the functions used in the VI (but not necessarily in subVIs).  Then, as this idea states, that version would be maintained in further editing unless features are added which are only present in newer versions.  There seem to be no benefits to restricting to the current version if it is not required.  If there was a menu in the Save As dialog (or in the File Properties I guess) with compatible versions, then individual files could easily be saved back without creating a new VI source tree.  Also helpful would be a VI Method "Save For Earliest Compatible Version" or similar.

It's also frustrating to have Projects update to a new version, when the XML is still compatible with earlier versions - yes, you can manually edit the version number in the file, but it would be nice not to have to.

[RnDMonkey]

I think the idea of saving the last compatible version is a good one. It's exactly what the Zip format does with bytes 4 and 5 of its header, indicating the minimum version needed to extract, which is determined largely by the compression method used. Similarly, the VI could indicate the minimum LabVIEW version that is needed to support its internal workings.

I think in the case of separate compiled code, the VIs should be much more version-agnostic as far as practicable.