Upgrade dilemma

[pallen]

I've got a bit of a dilemma.

My new 8.6 Developer Suite was waiting for me when I got back from NI Week. I really want to install it and take advantage of some of the new features. But I only have about 7G left of hard drive space on my trusty lappy.

Seeing as how it's possible to save for previous versions, is it necessary to keep both 8.5.1 and 8.6 installed on the same machine if I want to provide occasional support for a couple of 8.5.1 programs?

[Omar Mussa]

QUOTE (pallen @ Aug 19 2008, 06:40 AM)

I only have about 7G left of hard drive space on my trusty lappy.

Disk space is cheap. At the worst case, buy an external USB or Firewire drive and transfer data.

QUOTE (pallen @ Aug 19 2008, 06:40 AM)

Seeing as how it's possible to save for previous versions, is it necessary to keep both 8.5.1 and 8.6 installed on the same machine if I want to provide occasional support for a couple of 8.5.1 programs?

If you can't test the code, how do you know if it works?

[pallen]

QUOTE (Omar Mussa @ Aug 19 2008, 09:03 AM)

Disk space is cheap. At the worst case, buy an external USB or Firewire drive and transfer data.

If you can't test the code, how do you know if it works?

I appreciate your response. But the obvious, "Buy a bigger hard drive" isn't really what I was looking for.

What I'm wondering is; Will I be okay with replacing my 8.5.1 installation with 8.6?

I have a couple of projects that were deployed on 8.5.1 But because those applications are tied completely to one-off hardware, I can't actually run that completed code on this laptop anyway. Although I may want to modify small things or perhaps a SubVI in the future.

With 8.6 installed, could I not modify the code and Save for Previous version? Or am I asking for trouble?

[Aristos Queue]

QUOTE (pallen @ Aug 20 2008, 09:27 AM)

With 8.6 installed, could I not modify the code and Save for Previous version? Or am I asking for trouble?

There are features of 8.6 that do not exist in 8.5, and if you've used those features, the save for previous still works but the VIs are broken in 8.5, where you would need to fix them up somehow. But if you steer clear of those new features then in theory save for previous should work for you. Of course, Newton had a theory, and it worked in most cases, but it had to be patched by Einstein for certain conditions. Will your VIs be "special cases"? I appreciate the vote of confidence in LV R&D's programming abilities, but while your faith in our perfection is admirable, a pragmatist might suggest that loading those VIs in 8.5 -- just to check -- would be recommended.

Also, you can't save for previous and then load the VIs in the runtime engine. Any VI that has been saved-for-previous must be loaded in the development system in order to be recompiled using the old compiler. So if your VIs are going to be deployed on systems with 8.5 development system, you're fine. But if you're planning to load them with the run-time engine, you'll need to pass them through the dev environment.

* I believe I will begin using "special cases" as a euphamism for "bugs" :-)

[jdunham]

QUOTE (pallen @ Aug 20 2008, 07:27 AM)

I appreciate your response. But the obvious, "Buy a bigger hard drive" isn't really what I was looking for.

What I'm wondering is; Will I be okay with replacing my 8.5.1 installation with 8.6?

I have a couple of projects that were deployed on 8.5.1 But because those applications are tied completely to one-off hardware, I can't actually run that completed code on this laptop anyway. Although I may want to modify small things or perhaps a SubVI in the future.

With 8.6 installed, could I not modify the code and Save for Previous version? Or am I asking for trouble?

I really don't think this is worth the trouble. It's an annoying nightmare that never ends. I had one situation where I had LV 8.2.1, and the customer was sticking with 8.2 (since NI wanted to charge $ for that .1 upgrade). It's pretty much impossible to get work done in the new version without saving everything, since closing any front panel will hit you with a dialog box. Then if you save everything locally, it becomes difficult to see which VIs actually got modified with your changes. I was using version control, so it looked like everything need to be checked in.

Sure you can figure it out from file modification times, or keep good notes, or keep saving the entire hierarchy to a new location with "save for previous version..", but I found it very anti-productive and I finally got the end-user to upgrade and put me out of my misery.

Doing it again, and if I had had a disk space issue, I would have copied labVIEW 8.2 itself to an external hard drive and tried to run labview off that, then trying to maintain a program in the wrong version. I think you'll regret losing your 8.5.

[Dean Mills]

QUOTE (pallen @ Aug 20 2008, 09:27 AM)

I appreciate your response. But the obvious, "Buy a bigger hard drive" isn't really what I was looking for.

What I'm wondering is; Will I be okay with replacing my 8.5.1 installation with 8.6?

I have a couple of projects that were deployed on 8.5.1 But because those applications are tied completely to one-off hardware, I can't actually run that completed code on this laptop anyway. Although I may want to modify small things or perhaps a SubVI in the future.

With 8.6 installed, could I not modify the code and Save for Previous version? Or am I asking for trouble?

If you have a choice to upgrade you should upgrade. The upgrade on our software package was quite painless except for some issues with the OOP version of the report generation toolkit and a couple of other VI's that NI and Meikle has that are the same name. Building exes with this situation is interesting. But all in all for about 4500 VI's and type def's it only took about 5 hours to load and fix the broken code. We are still testing it but there doesn't seem to be any major issues or bugs. We have upgraded a couple of customers in the field already with only one incident which took about 1 hour to fix.

However, we maintain a copy of the code in each version of LabVIEW back about 4 LabVIEW versions with SVN. Older than these projects are generally orphans that contain information on which versions of LabVIEW they werer built in. We try to maintain backwards compatibility with all version but there is always something that gets missed after a projects hits the 3-4 year mark in age.

Since LabVIEW 8.2 came out I have invested in a usb drive and VMWare. I maintain a fairly clean copy of Windows and when a new version of LabVIEW comes out I create a new VMWare copy of the base Windows and install LabVIEW and all the other stuff. I generally find 10Gigs to be a big enough partition. When I need to support or upgrade an older project I open VMWare corresponding to the version of LabVIEW and use it. Right now I am compiling a bug fix for a LabVIEW 8.2.1 project.

Overall I am quite pleased with the ease of this upgrade compared to others. The 4 DVD's we received and the new installer screen at the beginning of install is a tremendous leap forward.

Dean