Managing multiple versions of shared libraries between multiple projects and developpers

[j.eggs]

We are a team of multiple developpers and could work daily on multiple projects. We track our changes using SVN and create libraries for our shared and reusable code.

We face now a structural challenge for the proper configuration of our applications. Let's summarise a common situation:

Project A uses library X

Library Y uses library X

Project B uses library Y and library X

We can have the libraries available from a common location to be available for all our projects. But how to handle new versions of the libraries? For example we create a version 2 of library X to be used by project A, but project B still uses version 1 of library X.

We are thinking about having all required versions of the libraries available on disk for each project to use the appropriate one, we cannot deal with one unique version available at a time (like it seems to be when using VIPM) because we could work on multiple projects on one day and it would be painful to install the required library version each time we open a project. How do you handle this?

Having library_X_v1 and library_X_v2 available on disk is not a problem, however updating project files to use v2 instead of v1 of a library is painful in such a case because the references to each library's file need to updated.

Thank you in advance for your advices.

[Domenik]

There was some presentation regarding what you are running into at the GLAsummit i think. I was not able to watch the presentation but I think this is what you are looking for:

Project Dragon 

[j.eggs]

That project sounds really interesting, I'll definetly keep an eye on it, thank you.

[ShockHouse]

Have you thought about using PPL's for this case? You could have the two versions of the PPL, and switching what PPL a project points to is incredibly easy, especially if they have the same name since they are the same library.

[JScherer]

Would using Git Submodules help you? https://www.youtube.com/watch?v=iv7WwDgyb0U https://delacor.com/how-to-organize-your-large-labview-project-using-libraries/ https://labvolution.com/using-git-submodules/

[j.eggs]

@ShockHouse

I never used the PPL's before but gave a try and it seems to be a good solution, thank you! I still need to play a bit more with them to see how it works with nested/dependent PLL's, it is not so obvious to avoid cross-linking errors.

@JScherer

Thank you for the very insteresting links. We are using SVN instead of GIT, but I saw that the equivalent is svn:externals and we already use them with lvlib files and it already helps a lot. However it becomes tricky to avoid cross-linking errors with nested libraries but this seems to be where PLL's can help us.

[paul_cardinale]

During development, we always use the latest versions of code in our common repository.  When we deploy, each deployment includes copies of all dependencies.  So future changes don’t impact existing deployments.  If we need to incorporate an update into a deployment, we regenerate it.