Automatic software version numbering for development team

[Eleventen]

Hello,

Recently I was approached by my supervisor to clean up our software development processes. One of the issues we encountered was software version numbering. My suggestion was to use the usual [big function release].[small function release].[bugfix] format. The problem is that, my supervisor really wants something which automatically numbers LabVIEW programs developed at our team (for example: SCM revision numbers), because he is afraid that some developers might forget to update the version numbers and then the program versions will be untrackable. Since we will also develop for external customers I would seldom the idea of a "non-standard" version numbering.

Is there any tool, which can handle version numbering automatically based on some concept? Or a tool, which warns users to change the software's version number when uploading it into our SCM repo?

Thanks for the help!

[NeilR]

The version number of every VI is incremented each time you save it. It's viewable by selecting 'Show revision number in titlebar" under Tools > Options > Revision History.

It is also programmatically accessible. You could use this in some way ... but changes to sub VIs of a main VI will not cause the main VI revision to increment ...

[cbutcher]

It's not obvious to me from your question if you're building your code into something (PPL, VI package, executable etc) or running in the development environment from the source code directly, but if you are building something and it's only that thing/those things that you want to store with incrementing version numbers, you could consider using a pre-build VI to read, update automatically or prompt for major/minor/bugfix type increment, and then write that version as part of the build artifact.

It's probably possible to also have the VI call into your SCM tool and use a templated commit message or tagging system, but I guess that's a little more out of the way.

In the same spirit, (at least for Git) you can have pre-commit hooks which call an executable (which could be a simple LabVIEW exe if wanted) and do the same thing (prompt/update + add to commit message). I don't know enough about commit hooks to be sure how you'd go about doing that though. I'd guess other SCMs have similar tools.

[Bob_Schor]

I'm assuming that SCM stands for "Source Control <something starting with M>".  I, myself, use Subversion, which gives each Revision a "Revision Number" that is part of the checked-out Working Copy (I'm using SVN terminology here).

When you build an Executable in LabVIEW, one of the options in the Build routine is the Version Number, made up of 4 parts, called Major, Minor, Patch (or Fix), and Build.  One the one hand, you can set all of these "by hand" (I, for example, set Major, Minor, and Patch this way), and can set Build to auto-increment (so every Build is different).  You can also set all of these elements programmatically using tools that have been available for at least the last 4-5 versions of LabVIEW as "Get (or Set) Build Specifications" -- look on the Application Control Palette under Application Builder (if you don't see it, look in the LabVIEW Tools Network for "Hidden Gems in VI.Lib").

While on the subject of Building Executables, there's a nice feature called a "Pre-Build Action" that says it lets you run code before the Build takes place.  "Aha!", you might think, "That's the ideal time to update the Build according to the current code's Revision Number".  If you search this Forum for "Pre-Build Action", you can find discussions about doing exactly this, including some posts from me that explains that NI "crippled" this functionality by caching the Version Number before the Pre-Build Action, so any change you make takes place on the next Build.  There are suggestions about how to fix this (from Hooovahh and from me, essentially saying "Build Twice"), and if you follow the link to my Idea on the Idea Exchange (and Kudo it if you think NI should fix this flaw), you can see that there are other ways to accomplish this goal.

Good luck.  If you find another solution that works even better in your situation, post it and mark your post as a Solution for other Forum users with similar questions.

Bob Schor 

[NeilR]

"Management"  looks favourite Bob.

I think many people have been down this road of trying to automate version control.

It would be great to have an SVN type system built directly into the LV project structure.

[cbutcher]

If you're using any of these then you can have it built in. Too bad that doesn't include any of Git, SVN or Hg.

I've heard a lot of talk about the TSVN toolkit but I've never tried it myself - the screenshots make it look like you can use it from inside the project window though.

For me, using Git Bash is fine - with LabVIEW development, there are already a bunch of overlapping windows half of the time - at least this has a separate toolbar icon 🙂

[Bob_Schor]

To "automate" Version Numbering, you need to consider the following questions:

• Do you want to display a Version Number when running the LabVIEW code in Development mode, when running it as an Executable, or both?
• When do you want the Version Number to be changed?  Do you want any part of the Version Number to be "manually" changed (e.g. Major, Minor, Patch)?  Do you want part to be "automatically" changed (e.g. Build, either from Version Control or auto-incrementing)?
• Where do you want to store the Version?  Note that if you are using LabVIEW Project, and have a Build Specification for your Top Level VI (and a Project can have many Top Level VIs), then each Build Spec contains an internal Version Number accessible by appropriate LabVIEW Function Calls.
• Assuming you decide to store the Version within the LabVIEW Project, how will you ensure that it is updated appropriately, i.e. that it reflects the correct Build reported by the Version Control System?  [This can be tricky, and you might need to live with "off-by-one" -- think about it ...]

Sorry, I just ask the questions, I don't have All the Answers.  As they say, "It Depends".

Bob Schor

[Eleventen]

Hey,

Thanks for all the answers... I'm pretty new to these forums so I think I need to clarify a few things 🙂
Currently we have a test system development team and a test execution team.

The test developer team creates application, which are built into executables and used by the execution team, the developer team or external personnel. The version number also has to be visible on the main front panel of the executable, since this has to be marked on the test reports.

Our goal for the development team is, if test bench or any software is being developed, then the version numbering to be tracked automatically by the source code (either when a commit or push action is performed to our Git repository or when a new executable is built). Right now the struggle is, that our management does not believe that version numbering will be incremented "manually" by the development team (I have no idea why this assumption is made... probably because our software development processes are being figured out right now), so they would prefer a "dummy-safe" method for this, either by automated version numbering or some sort of unavoidable prompting method.

I will read through all the comments, but if any of this information pops up anything new I'm happy for all the help I can get 🙂

[James_W]

There is a function call (Get application info) which will return all 4 build numbers of the application. The simplest way of proceeding would be to include this in the code, wire it directly to your FP indicator and never touch in again.

In the development environment the return value is that of the LabVIEW EXE, in the runtime, it is that of the compiled EXE.

A simple first test by the test team to verify that the code number matches what they expect is all that is needed from there on down.

Just 'KISS' and then minimal problems

James

[Bob_Schor]

A couple of comments on @James_W post:

• I cannot find "Get Application Info".  The "Get Build Specification Version" function has already been mentioned here.  This function requires a Build Specification in a LabVIEW Project.  I've used it in Executables, but I don't recall whether or not I've tried using in in Development Mode.
• A key specification of the Original Poster is that the returned Version would auto-increment (or otherwise automatically change) as code was submitted.  Several suggestions linked extracting Revision information from the VCS during the Commit/CheckIn step, thereby linking the reported Version Number with the Revision number in the Code Repository.
• Perhaps I didn't understand what you were suggesting (particularly as I don't know what function you were suggesting).  Perhaps a tiny code snippet?
• If, in the Development Environment, the return value is that of LabVIEW.exe, how is this helpful to the problem at hand?

Bob Schor