Why Are There Yearly Full Labview Installations Versus Upgrades?

[Steve_G]

Hi All,

I see that the discussion "Announcing the LabVIEW 2010 Platform beta" has just been closed.  I have a related question that I've asked NI engineers about on different occasions but have never really understood the reply.  Hopefully this won't open up a can of worms...

For a while now NI has released a yearly version of Labview, along with the semi-annual bug-fix.  Each new release (8.0, 8.2, etc) is a full-blown new installation of Labview.  This causes a number of issues for me, my company, and my customers:

1. The hard drives on my development computers fill up with all of these different versions.  I have a couple of older laptops with relatively smaller hard drives that just can't handle another full installation.
2. My software is constantly evolving as upgrades.  What I mean is that in 2008 I produces Main.exe for customer A using Labview 8.6.  Since then I've made improvements and upgrades to the software.  Last Oct I installed Labview 2009 and customer A wants the latest upgrades.  I either have to save 100's of vi's as Labview 8.6, or my customer has to install new run-time engines and drivers.  If I had kept the code in Labview 8.6 then I simply could have sent the customer a new version of Main.exe and it would have been really simple.
3. My company keeps track of software versions at customer sites (ie, version 1.0 of Main.exe) and now we have to cross-reference that to a chart that shows what version of Labview it was written in, in case that customer has questions or problems.  With 100's of customers it is getting more difficult.

Don't get me wrong.  I think Labview is great.  We just have to limit ourselves to installing new versions of it every 2-3 years to limit the hassles.  And, yes, I'll acknowledge that they are just hassles.  However, if other companies can release upgrades on a regular basis (how often does Windows demand to be restarted due to an automatic upgrade?) that don't require installing all new software then how come Labview can't just be upgraded?

I imagine that part of it is marketing - NI can announce an all-new release and that sounds better than the word "upgrade".  But to many of the users yearly "new installations" cause problems.  Why can't NI simply upgrade Labview each year and still call it a "new release" for marketing purposes?  And why does there have to be a new Labview Runtime Engine with each installation?  That's just something else that I need to send to customers for their "upgrades"?

OK, that's all for now.

Steve 

[Ben]

Too many questions!

I'll try to exaplain the subject line.

In the old days there were updates, but because a large part of LV is developed in LV this required mass-compiling. THe last time they released an update like that it took ages to complete and a lot of us screamed. So the next version came out pre-compiled and was used in marketing.

Ben

[Mark_Yedinak]

This doesn't answer your particular question but might I recommend that you get yourself a source code control system. I recommend getting SVN. That way you can keep a branch of your old code available for your customers as well as keep utilize source code control in your development environment.

[RTSLVU]

---

1. The hard drives on my development computers fill up with all of these different versions.  I have a couple of older laptops with relatively smaller hard drives that just can't handle another full installation.
2. My software is constantly evolving as upgrades.  What I mean is that in 2008 I produces Main.exe for customer A using Labview 8.6.  Since then I've made improvements and upgrades to the software.  Last Oct I installed Labview 2009 and customer A wants the latest upgrades.  I either have to save 100's of vi's as Labview 8.6, or my customer has to install new run-time engines and drivers.  If I had kept the code in Labview 8.6 then I simply could have sent the customer a new version of Main.exe and it would have been really simple.
3. My company keeps track of software versions at customer sites (ie, version 1.0 of Main.exe) and now we have to cross-reference that to a chart that shows what version of Labview it was written in, in case that customer has questions or problems.  With 100's of customers it is getting more difficult.

---

I'll take a crack at this with my limited experience...

1. Personally I ditch the old versions as I go.  Right now I only have LV 8.2.1 and LV 2009 installed. I see no reason to keep all the intermediate versions. I only have 8.2.1 installed becaus my company jumped from LV 5.11 to 8.0 and we still have a huge codebase written in 5.11 and 8.2.1 is the newest version that can directly open and upgrade LV 5.11 code.

2. If you build your customers an installer the new runtime will be included. I have not ran into any instrument drivers that need to be changed from one version to the next.

To me you would not want to send a customer just the "main.exe" anyway. New versions should be installed seperatly in a new location. So the old version can be use as a fall back if adding the new feature broke something else.

If they overwrote their working "main.exe" with a bad "main.exe" they would be screwed until you could send them another copy of the old one.

3. Don't know what to say here besides, yes and as someone else said invest in a good source control system 

[Matthew_Williams]

I'll second Mark's recommendation on source code control.  I am our only LV programmer and

it has been invaluable to me.  Put the repository on the network and backups are automatic.

Another suggestion is to setup individual virtual machines, one for each version of LV to be supported.

I have installed multiple versions in the same machine and it can be done but it is very tedious

and prone to strange errors.  Now I have a vm for each version I have to support and everything

just works.  Using virtualbox, but there are others.  Host is CentOS (Windows is supported), vms

are XP, Win7, etc. as required.

Matt

edit: Virtualization also makes it easy to move your work environment to new hardware, plus

has other nifty advantages.

Message Edited by Matthew Williams on 03-22-2010 04:59 PM

[Coq_Rouge]

I have a strong feeling that the motivation for this is purely economically. A problem for NI have been that to many people have been happy with their current Labview version, so they have not upgraded. And Labview do not earn money on such customers. Ni like all other companies need to have some income in order to pay workers salary and do product R&D(even if much of this department have been moved to China). But anyway this is the current situation and we have to live with it. A labview version will not expire the moment a new version is launched. So we as customers must look at the cost benefit numbers and decide what to do. Stay on the current version some time, upgrade via SSP etc. Or perhaps change to a text based programming language. Another thing is that if the customers feel that a software company, do have a to "greedy" license policy it may very well backfire. If a software is popular enough and has some sort of licensing strategy/protection. Some people will find a way to bypass this. And post it on the internet. Using such a bypass is not legal and will never be legal. But many may be tempted anyway. As they may have a feeling that they have paid enough as it is.

[muks]

see this discussion too

[pallen]

The answer to why is simple.  Continuous improvement. 

Microsoft has dropped support for Windows XP and pretty soon any new systems are going to be Windows 7...and inevitably that will be replaced too.  When MS releases an "update" that changes something relevant to NI, they would occasionally have no choice but to update their own software as well.  

NI hardware continues to branch out into different fields.  Existing hardware is reconfigured to work with faster or more cost effective components and that too means changes to software to fully realize the benefits of those changes.

Multicore.  GPU.  Ram beyond the old 3G limit.  If LabVIEW didn't embrace these new technologies, cutting edge developers would have no choice but to drop it for a tool that did.  (And that would make kitty cry) 

All that said, it gets frustrating for us too.  For most of last year and part of this year I was still starting new projects in 8.6 even though we had an SSP and latest LabVIEW versions.  There was concern that 8.6 development on machines that had newer versions of LabVIEW installed alongside might cause problems.  On our larger projects, this was a risk we didn't want to take.  

LabVIEW can't stand still.  And rolling out free upgrades for life is also (unfortunately) not an option.  All we as developers can do is try to make smart choices about how we purchase our tools and when we choose to upgrade them.  

[Steve_G]

Thanks everyone for your explanations and input.

We also use source code control, along with network backups of each released version.

My main questions centered around why there is a completely new installation every year and I think I understand that now.

Steve

[Mark_Yedinak]

---

Steve_G wrote:

Thanks everyone for your explanations and input.

We also use source code control, along with network backups of each released version.

My main questions centered around why there is a completely new installation every year and I think I understand that now.

Steve

---

I highly recommend keeping your SSP up to date. With that said though it doesn't mean that you must upgrade to the new version when it comes out. We often lag behind and even skip versions here. We maintain our SSP so we get the updates but if there isn't a compelling reason or we are in the middle of a major project we hold off updating our version of LabVIEW. However, we like the ability to upgrade when we want and find value in the continued support so it is a given that we maintain our SSP.