Set a target version when saving

[cbutcher]

I'd like the ability to set the target version of LabVIEW when I use the Save, Save All, etc commands.

A similar idea exists here: LabVIEW Compatibility Modes, but that idea focuses on retaining the existing version of a VI when it is opened, assuming no newer-LV-version-requiring changes are made.

I'd like to (additionally/instead) be able to choose from a dialog box/enum/etc which version my saves should target (older than the current version of LabVIEW I'm using).

Essentially, this is just the Save for Previous as a possible default save (with the default target being the current version). Since you can't Save for Previous on top of the code you have in memory, I think it would be nice to have this option.

[wiebe@CARYA]

Effectively this would allow us to maintain older code in newer versions, without upgrading.

It would be really convenient if that was possible.

[Bob_Schor]

Sorry to be a Wet Blanket, but (speaking from Sad Experience) the issue is when opening a VI in one Version when the VI being opened is in another Version.  There are three possibilities:

• The VI being opened is more recent than the VI trying to open it (whether the VI is already open, or was the "Last Version Used" and thus the default for opening VIs).  In this situation, you get an Error Message saying you need a more recent version (and thanks to NI for telling us which Version we need).  So the VI remains unopened, and "intact".
• The VI being opened is the same as the current "runable" LabVIEW (my term for the version already running or the "default" version).  No problem, can open and edit VI, can save it, and only need to worry about screwing up the code (which is why we need to use Version Control).
• The VI being opened is older than the current "runable" LabVIEW.  As long as we don't save this VI, we can examine it, play with it, run it, edit it, etc., but if we save it, we make it unable to be opened with the Version that created it!  And if it is one VI in a big Project that we save to Version Control, we won't know about the problem until we try to open the Project in the original Version (and can't open the saved VI).  Here, it seems to me, it would be "nice" if LabVIEW, when it opened a VI that was from an Earlier Version, would pop up a Dialog Box simply saying "You are opening a VI last saved in LabVIEW XXXX with LabVIEW YYYY".  Nothing more would be needed, in my (not-so-humble) opinion -- you would know when opening a VI that you might have a problem when you saved it (and could take appropriate steps before any damage was done).

Bob "Curmudgeon" Schor

P.S. -- I've made this very error, opening a LabVIEW 2016 Project by double-clicking the Project file and not recognizing that LabVIEW 2018 popped up and opened the Project).  I find out the next day when I Update on my other machine and find "Oops, can't open 5 VIs in the Tree because they are the wrong Version of LabVIEW, drat!" (except I might not say "drat").

[cbutcher]

I'll use "running" for the version of the LabVIEW application that you've opened, and "targeting" or "targeted" for the version that you're aiming to save to with this hypothetical feature.

As you highlighted, we could consider 3 situations (I'll number your suggested categories):

1 - The VI version is newer than the running version. Nothing to do, can't open, move on (via nice dialog box). MyFile.vi is unchanged (as you already explained)

2a) The VI version is the same as the running version, and you are not using this suggested feature. Same behaviour as current, you open the VI, save it in the same version, nothing changes except whatever code changes you intentionally made.

2b) The VI version is the same as the targeted version, which must be older than (or the same as, like in the current system) the running version. Same behaviour as if you were running the targeted version, which is the same as the file version (case 2a). So only intended changes.

3) The VI version is older than the running VI, but is not the targeted version (so slightly different under this proposal than the current case, because some of your third group will fall into 2b). 

3a) - the VI is older than the targeted version. This is what we have now, all the time when opening older VIs, and as you described. A dialog box might be helpful, because then we'd know we're going to update, but essentially this is an unchanged situation compared with the current status.

3b) - the VI is newer than targeted but older than running version. It seems reasonable you should still be able to open the file, but now saving it depends on it not having any features newer than the targeted version (i.e. it should be able to be saved using the existing Save for Previous feature). If so, you're probably fine. You might not even mind the version changing (because it became older - no new problems opening). You might still want a warning on opening though?

As an alternative, I might suggest that in the 3a case (your 3rd group in its entirety, I think?), you'd ideally want to be able to save a copy of the file into your currently open project. This might be nice, but is probably beyond the scope of the original idea here, which I hoped was effectively already half (or more) implemented via the Save for Previous feature.

I'd also be tempted to claim that if I'm depending on source code in other projects/repositories (not necessarily the same thing, but anyway) I have an organisation problem. Which isn't to say it doesn't happen, and of course it's something to consider, but I don't think this idea makes that problem any worse.

On the other hand, if all my code is in 201X, and I want to use 201Y because of all the wonderful IDE improvements (even knowing I can't use Y's new coding options, Channels, VIMs, Maps and Sets, whatever is specific to Y and not X), I can use this proposed option all the time, and perhaps get rid of my installation of 201X.

It also simplifies downloading other code via GitHub, GitLab, etc and then needing to work in a specific version. Doing that with the current system is a huge frustration - if I want to work on the JKI VI Tester, either I install LabVIEW 2013 and lose any productivity improvements since 2013 (I suspect quick-drop shortcuts might be close to the top of the list for me in that case, but YMMV), or I work in whatever version I like, but have to Save for Previous (into a different directory) and then copy-paste it over the source I cloned before committing. Makes it more difficult to work and slower to boot... (I suspect, typing this, that I could also clone it, remove the remote, and then clone it somewhere else, and backsave into that second directory, and only commit from there... this is a better workflow, but still not ideal).

Regarding your P.S. - I know the feeling. I'm not sure "drat" is what passes my lips either... 

[Darren]

National Instruments will not be implementing this idea.