How to handle version changes? Strategies?

[cebailey]

We're struggling with version change issues. Most recently we tried to move from 8.5 to 8.6 and lost about a week of project time while we tried to make it run well. The problem was that the Development Environment would crash several times a day while doing block diagram edits, losing unsaved changes. We never found any clues as to why. It would be one thing to debug a VI that crashes, but when it is the LV editor itself that is crashing, how do we work on that?

Anyway, we have a policy here of freezing software updates for projects that are close to completion, because buggy updates so often delay project completions, and this triggered a return to 8.5, which is where we remain now on that project.

But now we can't install and use the VI Analyzer we just bought on any of the PCs tied to that project, as it demands 8.6. I do have one PC that is completely disconnected from this project, and it runs 8.6, so running the Analyzer there may be useful, but still messy.

How do you handle version changes? How often do you try to follow the updates? How often do you need to go back a version? Do you maintain different versions? Is it even possible to run multiple versions on an individual Win XP PC?

Thanks!

[TCPlomp]

I have installed several versions of LabVIEW on my system.

Most of the toolkits are only installed in the latest versions. There are ways to install toolkits on multiple versions.

And I think that toolkits as of LabVIEW version 8.6 can be installed on several LabVIEW verions.

Ton

[Ray.R]

My recommendation is to stay with the same version until either the project is completed or after a release.  Although it has always been smooth in the transition (been doing this since LV6.0), there are similar stories to your out there.

When a client has an update, the software development does not follow immediately. It is done after a milestone is met, which usually means a release is made.  The code is frozen and then we see how moving forward with a newer version will affect the software.  If an adverse situation would occur, we would simply revert to using a copy of the frozen sources.  There is no need to uninstall the more recent version, as long as you make sure NOT to open any of the working files with the newer version (the problem is if you make the mistake of saving the file with the newer version).

Going back to a previous version seldom occurs.  I think it has happened once when LV8.0 was first introduced.  We had gone back to LV7.1.

Typically, when moving forward with a version the previous code remains frozen.  And there is no reason to maintain older code / version.  That may depend if more than one branch of the code exists and you have one branch done in one revision and the other branch(es) done in another version.  I don't think that would be a recommended practice, although if well managed, should not be "hazardous".  

Yes, absolutely.  You can run many versions of LabVIEW on the same PC.

As for your analyzer, you may want to create a copy of your code, and open that onewith LV8.6 and carry out the analysis on it.  Meanwhile developpingyour code using LV8.5. 

Hope this helps,

RayR

[cebailey]

Thanks, guys. I think I should do the multiple version installation route you did.

Are there any tricks to setting it up?

TonP, can you paste the text of the url for the link you gave? When I follow the link I get what looks like either broken HTML source or perhaps a goulash made from percent signs while the cat walks around on the keyboard. Though I must admit that some other installation instructions do kinda look like this.

[TCPlomp]

Try two.

 Basically you create a fake LabVIEW directory in the lowest LabVIEW version install and copy everything to the proper directories.

Ton

[ASTDan]

I have heard of peple running virtual PC for each version of LabVIEW they have.

http://en.wikipedia.org/wiki/Microsoft_Virtual_PC

I personlly wait to upgrade to a new version of LabVIEW in between projects.  This avoids those headaches.

I would also encourage you to use source code control if you are not already doing so.  This makes reverting back to a stable version much easier.

I like tortise/svn, but there are a lot of choices 

http://tortoisesvn.tigris.org/

Dan

[Hueter]

Check out the Labeled Upgrade Analyzer tool on NI Lab. This tool is meant to tell you what parts of your 8.5 VI's might cause problems when upgrading to 8.6.

www.NI.com/Labs

[cebailey]

Thanks, all!

ASTDan, the great majority of this project, at this stage (nearing the end), is just one programmer. I figured source control (which I have never worked with) had no place with a single programmer project. Should I reconsider? My method of leaving a recovery trail is to copy the project folder, which contains the Project Explorer file and all my work that it points at, into a backup area on a separate tape-backed network drive. The backup area is outside LV's search scope. Does anything sound worrisome about this, and would source control fix it?

TonP, thank you for link two. It works fine. I can roughly imagine the setup already.

[ASTDan]

I am just one programmer and have adopted source code control recently.  I really like it.  I think you will find it is easier to work with than your current system.  With source code control you can add comments every time you "commit" your code telling you what has changed.

I am still a SCC newbie, and have a lot to learn but I felt comfortable working with it after a few days.

What I did to get started was just create some junk text files and played around with them before I put my LabVIEW projects.

What I really like about Tortisesvn is it is independant of LabVIEW and you can put any files under SCC i.e. drawings, wiring digrams, manuals, specifications, etc.

I think what your doing is fine just labor intensive.  Using source code control you can essentially create a copy of your files and save them in your backup area with one click. 

Hope that helps!

Dan

[TCPlomp]

---

ASTDan wrote:

What I really like about Tortisesvn is it is independant of LabVIEW and you can put any files under SCC i.e. drawings, wiring digrams, manuals, specifications, etc.

This is a misconception, everything you can put in a LabVIEW project (which is every file) can be added via the LabVIEW SCC-plugin to SCC.

At work we use MS sourcesafe (i'm not that big a fan) and at home I use SVN with TortoiseSVN and the Pushok plugin for direct LabVIEW access.

If you use SVN as a sole developer I would go for the Pushok option, if you use it for multi-developer I would go for tortoise.

Ton