Handling multiple versions of Reusable Library

[LV User]

I have different customers using different version of labVIEW, I have all my reusable library stored in SCC (Perforce), Now I am having to manage my reusable components for multiple version of LabVIEW. What do you think is the best way to manage the code, I can do a branch of the code but it duplicates the code and every Issue I find, I will have to go and fix all the supported versions of LabVIEW. I am sure many developers would have gone through this, Can anybody suggest the best ways to do it. It will be also useful for many new engineers like me. Is there already a thread where we have discussed this ?

With Regards

Rajkumar

[Francois Normandin]

You can make packages of your code in the oldest version you need to maintain. Then deploy and compile them if the version is more recent.

No code duplication needed. Check out VIPM... it does all you want and more. It handles versioning, distribution and installation. It also integrates in the project environment.

[crossrulz]

I have been looking into this for the last few months and VIPM is the only thing that I have found that will do this. And it does it well.

[crelf]

Add my vote for VIPM too - we use it, and it's an awesome product. Stay tuned for even more awesomenessitivity in VIPM 2010...

[Francois Normandin]

...awesomenessitivity...

Repeat this quickly to me three times at the BBQ, without laughing, and I'll buy you a beer...

[jgcode]

Add another vote for VIPM Pro from me too.

[danielsan]

Add another vote for VIPM Pro from me too.

Add one vote against VIPM for me!

Maybe I don´t get the point but I can´t see an advantage in using VIPM. If I install all the dependencies in user.lib or on of these directories I´ll never have the chance to do a quick setup of my libs on another pc.

Using scc you can just bind your libs as externals in your projects.

With a trunk, branches, tags structure create release branches for every project and every lib.

Branches are not code duplication. You do your bugfixes on the trunk an merge this to the release branches (if necessary). Then you´ll create a tag with fixed revision numbers of the libs in your project.

This way you´ll have your setup complete with one checkout.

You don´t have to use another third party software and you don´t have to install things on other pc because it´s all there.

[crossrulz]

Add another vote for VIPM Pro from me too.

I've was playing around with VIPM 2010 yesterday and found that I can now build all the packages I want with the free community version. There used to be limitations, but it looks like JKI decided to open it.

Here are my major reasons to use VIPM: 1. It manages your user library for each version of LabVIEW you have installed, 2. You can define your palettes a lot more easily than using LabVIEW's palette editor, 3. You can install only which packets you need, 4. It handles packet dependencies (ex. my GPIB packet need my Wait packet in order to work). These are things a normal SCC just cannot do, or at least not cleanly.

[mje]

Just like danielsan, I use source code control to handle all dependencies. Everything is set up as an external to a tag via the SCC. I never touch vi.lib/user.lib for anything other than a few of the code bases I use that are distributed through VIPM.

[jgcode]

I've was playing around with VIPM 2010 yesterday and found that I can now build all the packages I want with the free community version.

This should have been you're 5th point

[danielsan]

Just like danielsan, I use source code control to handle all dependencies. Everything is set up as an external to a tag via the SCC. I never touch vi.lib/user.lib for anything other than a few of the code bases I use that are distributed through VIPM.

I even put these things like the openG libs I use in the scc. This way I can immediately continue developing on any other standard LV installation.