Build Installer LV8.0 - is this real??

[becktho]

Thanks Kennon for this information.

tst: Don't say that - I still got some programs (6.i) which use FP systems. But you're right, this year I'll update them all to LV8.0 ;).

Thomas

[JeffreyH]

What I'd like to see in future versions of the installer is a lot more flexibility in selecting add-on installers.

One Idea might be that LabVIEW just tells me what the current version of a certain installer on my development system is, but let's ME choose which version to include in my installer. I.e. I want to be in charge of deciding whether or not to include an older version of e.g. datasocket then the one that is installed on my own system.

As an Alliance Member we work for a lot of different customers. I need to be able to build the installers in my project at anytime independent of the fact that I have installed newer versions of certain add-ons since the last build and always get the same result.

Regards, Jeffrey

[Kennon_Cotton]

"I want to be in charge of deciding whether or not to include an older version of e.g. datasocket then the one that is installed on my own system."

Jeffrey, do you really want to be able to include a different version of supporting software that what is on your machine?  You have tested with the version that is on your machine, not with the older version.  So there is a chance that older version has a bug that is fixed in the newer version that your testing would have missed.  This seems like a bad idea to me, although the chance there is such a bug vs the cost/pain of the user upgrading needs to be considered.  I just wanted to get some more information before I put the suggestion down.

Kennon

[Ben]

Hi Kennon,

I appreciate all of the info you have shared in this thread and part of the challenge y'all are facing is the different types of end users.

In the case of end-user that use a copy of LV to run A application then the current approach NI has been using is valid and is nice in that the user cna do an image backup of their machine, load the new updates and test. If all is OK done. Otherwise, restore backup and we are OK.

In the case of integrators (like myself) that develop a bunch of different applications and turn these over our customers AND hope to support them in the future, we should be "freezing" our devlopment machines "AS-IS" and STOP fooling ourselves into thinking that we can support multiple versions on the same machine. If we want to support the old applications, AND develop in the new version, we start with fresh machines.

Am I understanding this correctly?

Ben

[Ben]

Another thought...

What about NI installers doing a complete backup of ALL NI stuff that will be over-written or deleted.

Then add the ability to "un-upgrade" NI software.

Ben

[Matthew_Williams]

I'll second both of Ben's comments.  We actually maintain two distinct development machines for
our application, one 6.1 and one 7.1 (RT code is 6.1, PC code is 7.1).  New development is done
on yet a third machine which is the latest patched 7.1.1.  I don't have a new machine for 8 yet 😉
We found that this is the only way we could hope to keep our builds consistent.  Serendipity has
provided us with enough licenses that we are actually legal, and all of this is for one developer.

As far as the application builder, just being able to document which versions of vi.lib files, etc.
were used for a particular build would be a great help.  Being able to pick and choose would
be very nice but if I could at least get a list that I could compare against the list for a future
build then I would know something changed.  This is not as big an issue now that we dedicate
a machine to each new development environment but would still be a very useful feature.
Creating a development distribution tree including all sub .vis for each project is certainly a
possibility but even then I am not confident that I _know_ which subvi LV is pulling from where.

Matt

[JeffreyH]

Jeffrey, do you really want to be able to include a different version of supporting software that what is on your machine?  You have tested with the version that is on your machine, not with the older version.  So there is a chance that older version has a bug that is fixed in the newer version that your testing would have missed.  This seems like a bad idea to me, although the chance there is such a bug vs the cost/pain of the user upgrading needs to be considered.  I just wanted to get some more information before I put the suggestion down.

Yes, I'm very sure.. It's all about letting the choice be with the developers. They know what they are doing (well, most of them I guess.. 😉

I think that the current situation is a nice default setting and would suite most developers but as an integrator I simply need the flexibility.

Let's say a customer requires a tiny change in a fileformat used by an application. I then need to be able to create a new exe and installer and distribute it to him. If the only difference with the previous version is my change to the source I know exactly what could or could not go wrong when I send my customer the new installer. Now, if the new installer includes other versions of drivers then the previous one there are more components that have changed. In the case one of these changes leads to failure on the customers system I probably have to go over there which costs us extra time and money.

Bottom line: it's all about control.. If I want to change one aspect of my app I don't want to be force to change other aspects (drivers or toolkits) as well. You know the old saying, if it ain't broke, don't try and fix it.

What about NI installers doing a complete backup of ALL NI stuff that will be over-written or deleted.
Then add the ability to "un-upgrade" NI software.

Now, this is a nice idea.. This is the same road OpenG is going with their Commander.. Having the ability to easily switch back and forth to different versions of installed packages.

Jeffrey

Message Edited by JeffreyH on 03-06-2006 02:43 AM

[Kennon_Cotton]

Well I've been meaning to reply to this for a while now (looking at the dates about 7 weeks, doh) right after my last posting I was out of the office recruiting and then didn't prioritize this back up. I was trying to decide if I should let "dead" threads lie, but I wanted to mention a couple of things and let you know I'm putting your feedback in some suggestions.

The idea Matt and Ben mentioned of "freezing" your development machines to keep around for developing future upgrades, is a good one. We actually do that here at NI with some of our build machines. VI Logger 2.0 for instance was developed using LabVIEW 7.1.1, NI-DAQ 7.something, FieldPoint 4.something else and so on. Plus the C portion of it was developed with Visual Studio 6.1 and certain service packs. So when we needed to build VI Logger 2.0.1, we fired up the build machine that we had used and made the modifications on there. That way we were changing as little as possible in that maintenance release. The biggest hurdle for us wasn't related to NI software (we were okay updating that), it was actually with Visual Studio, all our development machines had been upgraded to 7.1 and that had some pain associated with it, that we didn't want to go through since it wasn't required. So we were able to avoid that because we had this build machine "on file".

In order to comply with the configuration management requirements you / your company have laid out (or have enforced on you), you certainly may need a build machine for each product / project or even one for each revision of a product. That obviously could get a little pricey, but may be necessary. You have to balance the cost of buying a new machine versus the cost of upgrading to the latest drivers, testing your application with them and shipping those drivers to your customers. Those hours can add up and time is quite valuable to all of us. Besides, how could buying a new machine be bad 🙂 who doesn't want a new computer.

I think I'm seeing Jeffrey's idea now, why does it matter if the driver I want to include is installed on my system or not? That is something that is required by the current installer builder, it only knows what is available by certain files being installed. But what if we could select any old or new installer, installed or not and include it instead? That is something we'll have to think about. The main use case we were going with for this first version of the new installer builder did revolve around system replication where you want to get the exact stuff you have on your machine in the installer. With some of the complicated dependencies our installers have it may not be possible to select any version of a driver an include it, but it is something we should consider. A big problem I see is how do I easily know what is available if the installer hasn't been run on my machine.

The idea of being able to hop back and forth between versions or "un-upgrade" is not something I've heard discussed. I'll bring it up and the need for some customers to be able to develop multiple applications with different dependencies on the same machine.

I'll try to address one more item in this reply. Matt the best way we've found to know what went in a particular build and document it is through our Source Code Control software. When we have a release we set a label in Perforce, which will store a list of all the revisions (SCC revision not VI history revision) of the files in our "set" of files. We also create a build assumptions document that describes everything you need to know to get the code and build it and create the cd that went out (this is done separately in Word). I don't know if all SCC packages support the idea of a label, but I imagine most of them do.

Kennon

[Ben]

Thank you for the follow-up Kennon!

Since the time of this discussion I have implemented my own "Un-Installer".

I just have my IT people do an image backup of the machine before I start loading disks.

So far, so good,

Ben

[cebailey]

Hope an observation from a new user is useful...

It's awfully intimidating to see installation sizes on the order of a gigabyte, and all the ins and outs of what components need what other components sound beyond my computer skills - must be a huge amount of detective work and memorization and experience to make sense of an installation or accurately predict what I might distribute to an end user in my organization.  Was I smart to get onto this LabVIEW bus?  Will my nonprogramming measurement partner balk at a 500 MB device driver installation (as I well might)?  How much work will it be just to keep all these things working together against a backdrop of frequent upgrades?  I'm just now tryng to reinstall MAX, which won't run anymore for some reason, and it's a startling commitment.

Here's the thing: the way I have done much of my DAQ until now is to write my own hardware drivers in assembly.

Hasn't something gotten way out of whack, if I can write DAQ applications from the ground up in assembly but can't practically comprehend a LabVIEW install?

But like I say, I'm new here...