LabVIEW Life Lessons #6 - Versions

[swatts]

Hello and welcome to my latest L³ Ramble

If you use source code control (SCC) then Kudos to you, this then will lead neatly onto version numbering

I've seen a fair few ways that you can version your source-code and this is what we've settled on. Guess what! it's not very complicated.

For every unique deliverable item we require a version number.

So......

For our main VI we have a version number and this is linked clearly (via the comments) to our versions in SCC. Clicking on the indicator will pop-up the details

Version info can be found in SCC comments and we also stick them in VI Documentation too. If they get too wordy we can link to another file or write a specific container.

On the block diagram we just use a version constant vi.

We use embedded exes and micro-services for some our programs and these will need versioning too.

Here we see that the bugreporting dialog is an exe called by the main VI and this one is on Beta Version 1:14.

For exes it's very useful to be able to query the version from the command line. Here's the code.

Using this we can send the command line bugreporting.exe --Version and it will respond on the std_out it's version number. It won't actually load itself as this is a dynamic calling VI not the actual bugreporting screen. We use this for auto-updating.

For Realtime systems we use similar tactics, but as well as something visible on the front panel, we also need to be able to query it remotely.

Here we query the rack info for a connected server and our version constant is front and centre.

In fact this applies to all embedded targets, for example we have PIC controllers that respond in a similar fashion.

Finally for FPGA targets we just embed a couple of controls on the front panel and these are then passed up to the host.

These are updated each time they are released to the outside world and not for every commit to SCC.

Here's some practices we've observed and DON'T do ..... you may have a use case that these apply to.

I've seen CLA level work that individually version numbers each VI, I guess this is instead of a pukka version control system. Seems very counter-intuitive to me!

I don't use the individual revision history options as part of LabVIEW, to my mind it drowns you in information you don't need.

In short I want to know what version of software is being used/ reported against and then be able to trace this back to a SCC release.

So far this has worked very well for us.

Lots of Love

Steve

10-July-2017 Here's an addendum based on a project I've been called in to support.

New rule: The version of the source-code needs to be traceable from source code control to the version of the built exe. I came across a project last week where I had no clue as to what version of the source code was used to build the version of the exe.

This option was used on the application builder.

The build version was then taken from this and displayed in the title bar. This is fine for the customer, but for someone supporting the code is was essentially useless. I could replace the source-code with an entirely new set of code and all it would do is increment to the next build.