Build Number

[Neil Pate]

Quick show of hands, does anybody actually use the Build Number in executables? I use Major.Minor.Bugfix, but never build number.

 

Perhaps this would be useful when using some form of continuous integration type processes, but by far on the projects I have been involved in or seen all the builds are done manually by the developer (and thus the version components are manually bumped). In this instance a new build almost certainly correlates with either a bugfix or a new feature.

 

Thoughts? 

Edited April 30, 2015 by Neil Pate

[hooovahh]

I do use build number to link back to source code control.  So this still means manually updating it every time which is a bit of a pain.  I've thought about ways of fixing this but I just live with it.

 

So when I'm making a build I'll set the Major, Minor, and bugfix to what ever is appropriate incrementing from the last version.  I'll then set the build to whatever the source commit number is.  So for SVN I'll right click the project, go to properties, and then use the commit revision number.  I have in the past taken the commit revision number and added one to it, because this would be the revision of the next commit but as long as there is a decent description in the commit I've never had a problem.

 

What this does for me is help isolate an EXE to source.  So years later we get a report saying this step failed.  In the report is says the EXE version was 1.2.3.534.  I then go to source code control, and find commit 534.  Hopefully there is a comment in the commit saying "commit build version 1.2.3.534" and I can roll the source back to that and see what the source was that made the EXE, that was ran when the report was created that failed.

[ak_nz]

I too use the build number for source control. When we don't use a build server directly we have a plugin (Tools menu) that reads in the project source SVN revision and allows the developer to build the appropriate build spec and then reverts the project file to prevent confusion. 

[mje]

We don't display the build number anywhere in the applications, but we do use them in release testing since the number can be extracted via Windows Explorer. When you've build your fifth release candidate and they're all labelled version X.Y.Z, you sort of need that last hidden number.

[ThomasGutzler]

I do use build number to link back to source code control.  So this still means manually updating it every time which is a bit of a pain.  I've thought about ways of fixing this but I just live with it.

 

So when I'm making a build I'll set the Major, Minor, and bugfix to what ever is appropriate incrementing from the last version.  I'll then set the build to whatever the source commit number is.  So for SVN I'll right click the project, go to properties, and then use the commit revision number.  I have in the past taken the commit revision number and added one to it, because this would be the revision of the next commit but as long as there is a decent description in the commit I've never had a problem.

 

What this does for me is help isolate an EXE to source.  So years later we get a report saying this step failed.  In the report is says the EXE version was 1.2.3.534.  I then go to source code control, and find commit 534.  Hopefully there is a comment in the commit saying "commit build version 1.2.3.534" and I can roll the source back to that and see what the source was that made the EXE, that was ran when the report was created that failed.

 

I really like the idea of svn revisions linked to executables like that.

I've attempted similar things but I'm not writing customer facing software so I'm not motivated enough to do all that manual stuff every time. Sounds like a good job for a pre-build action though!

In fact, I've tried solving it with a pre-build script but I never got it to a state where I liked it.

Has anyone? 

[joerghampel]

I'm using git, and because of its decentralized nature, there is no one incrementing commit number that I could put into the "build number" field. What I decided to do instead is:

• Create a tag in the VCS (which is just a named pointer to a commit) which is following the semver notation
• If building a Windows application
  • Write the tag info into the major / minor / patch fields of the build spec
  • Write the build timestamp into the description field of the build spec
• If building a source distribution
  • Append tag label and build timestamp to each VI's description (so it shows up in context help)
• Automatically create a readme file that is distributed together with the built package (.zip in my case) that shows project name, version info, changelog (all commit messages since last tag) etc.

After playing around with pre-build VIs for some time, I decided that I wanted more of a continuous integration type of tool / process, so I started automating the whole build process (I wrote about that here, amongst other places).

 

Executing a build specification has always the purpose of releasing an application or source distribution. So I made the creation of the tag in the VCS the starting point of my build process (my gitlab repository will then trigger a Jenkins task on my local build server, but manually invoking the build tool does just the same).

 

The build tool will first check the working copy for changes (or rather, the absence of any), then run some VI analyzer tests, read the tag name associated to the latest commit, update the build spec fields and/or VI descriptions, create the readme file, execute the build spec, create the release package (.zip), and copy that package to a local directory which is synchronized with my web server.

 

I run Dokuwiki and created a plugin that uses the gitlab API to read all tag labels for a given repository, and then automatically displays all available files for that tag label as download links.

Edited May 1, 2015 by joerghampel

[joerghampel]

LabVIEW 2014 also introduces a VI for editing the build spec version (which was possible before, but not as intuitive):

 

Set Build Specification Version VI

Edited May 1, 2015 by joerghampel

[Neil Pate]

I'm using git, and because of its decentralized nature, there is no one incrementing commit number that I could put into the "build number" field. What I decided to do instead is:

• Create a tag in the VCS (which is just a named pointer to a commit) which is following the semver notation
• If building a Windows application
  • Write the tag info into the major / minor / patch fields of the build spec
  • Write the build timestamp into the description field of the build spec
• If building a source distribution
  • Append tag label and build timestamp to each VI's description (so it shows up in context help)
• Automatically create a readme file that is distributed together with the built package (.zip in my case) that shows project name, version info, changelog (all commit messages since last tag) etc.

After playing around with pre-build VIs for some time, I decided that I wanted more of a continuous integration type of tool / process, so I started automating the whole build process (I wrote about that here, amongst other places).

 

Executing a build specification has always the purpose of releasing an application or source distribution. So I made the creation of the tag in the VCS the starting point of my build process (my gitlab repository will then trigger a Jenkins task on my local build server, but manually invoking the build tool does just the same).

 

The build tool will first check the working copy for changes (or rather, the absence of any), then run some VI analyzer tests, read the tag name associated to the latest commit, update the build spec fields and/or VI descriptions, create the readme file, execute the build spec, create the release package (.zip), and copy that package to a local directory which is synchronized with my web server.

 

I run Dokuwiki and created a plugin that uses the gitlab API to read all tag labels for a given repository, and then automatically displays all available files for that tag label as download links.

 

That sounds like a very thorough process, and miles ahead of most of what I come across. Is there a jealous HTML tag?

[joerghampel]

That sounds like a very thorough process, and miles ahead of most of what I come across. Is there a jealous HTML tag?

No need to get jealous. The whole process only works on some of my projects. With our own framework and reuse libraries, there's still some manual work involved, but it gets better all the time...

 

I'm not ready yet to just share the whole code, but you can definitely PM me if you have any specific questions.

Edited May 1, 2015 by joerghampel

[hooovahh]

Sounds like a good job for a pre-build action though!

LabVIEW 2014 also introduces a VI for editing the build spec version (which was possible before, but not as intuitive):

 

Set Build Specification Version VI

Yes it sure does seem like a no brainer that you could use the Pre-build action with the set build specification.  It was the first use case I had for the new 2014 feature.

 

Too bad NI wasn't thinking it would be used in this way, and as a result, the version assigned to the build is read before the pre-build action is executed.

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/In-building-executables-allow-Pre-Build-Action-to-modify-Version/idi-p/3056573

[joerghampel]

True that. Even before LV2014 and this very handy VI...

 

It was the fact that you can't modify the version from the pre-build VI that made me look into automating the whole process.

[eberaud]

At my work we let LabVIEW auto-increment the build number, but we manually reset it to 0 each time we increment another index. For example, if I fix a bug present in version 1.2.3.12, the next build I make is 1.2.4.0. Then in my SVN commit I put "Version 1.2.4.0" as a comment, which allows me to retrieve the SVN version by looking at the SVN log. If I forgot to include something in the build or to modify something that shouldn't involve an update of the first 3 indexes, then only the build number gets incremented, just to make sure each build has a unique build number (1.2.4.1 in my example).

[ensegre]

I devised a lame way, which sort of works with some manual steps, but which I fear is the source of frequent odd compilation errors which I observe; for my current project it holds and I'm not enough motivated to perfection it, but on longer term I think I'll have to.

 

I use git. I still rely on the project build specifications, not on a build script, so I have a build EXE and build installer step which I launch manually, normally just after committing to git. The former has a pre-build script which reads the HEAD identifier and the current date, and saves it as default value to a simple VI providing a string output; that VI is part of the project. One of the main panels of my application gets the version string from the small VI and displays it somewhere.

 

Drawbacks I see are that modifying a VI part of the project as part of the build creates unnecessary source diffs; and that the git SHA is quite criptic to end users as version identifier.

 

I also miss a way to name installers in a way reflecting their version; that I currently do manually renaming the Volume directory, I guess a build VI could take care of that easily too.

 

Pre-Build Action.viGetGitSHA.viVersionString.vi

[ThomasGutzler]

Modifying a vi during pre-build never really worked for me.

Usually the build process would complain that the source has changed and wanted to revert or update; both cause pain. They way I understand the build process this shouldn't happen but it did, so I gave up.

If it works for you, you can always revert that vi in the post-build to avoid source diff.

[joerghampel]

I create tags for each build. That way, I have "names" for my releases, like for example "v1.2.3". You can easily automate the creation and publishing of tags from within a pre-build VI or a build script. This might help you with naming your installers?

 

I also used to modify the source of a VI to store version information, and sometimes still do (it's an optional part of my build script now). What I like better, and what I do more often now, is create a text file which contains all sorts of information (kind of a readme file for the application). When run from an .exe, I read the version information from the .exe file properties and additional information from the readme file. When running the application from the development environment, I read version information only from this readme file.

 

For libraries, I write the version information (the tag name) to the VI description, so that every VI can still be identified after release.

 

PS: For my older projects, I do just as Thomas suggested: Modify the VI before executing the build spec, then revert afterwards.

Edited July 6, 2015 by joerghampel

[ensegre]

Thanks Thomas and Jörg, I agree on both, and partially thought at them myself. Indeed a text file relieves from a changed project vi, and can be inspected without launching the program; and a tag allows complete freedom about version format; perhaps though, tagging should be reserved to "meaningful" versions, i.e. one might want to tag only semistable distributables and not systematically every snapshot, which involves a subjective decision.

What I take home from this is - it's not that I haven't yet discovered some advanced option in the project explorer, it's that if I want something specific I have to program it myself with an automated build script.

Edited July 6, 2015 by ensegre

[hooovahh]

Yes it is possible to use tags that get read, or editing a constant on a block diagram.  But at the end of the day I want my EXE to show the correct version, when you inspect it in Windows Explorer too.  When you right click an EXE and go to Properties, then Details it shows the Product or File version.  This is a standard way for applications to contain version information.

 

Having a string constant on the BD that gets updated is just another way of showing a version which might not match.  For this reason I'd really rather just maintain the version with the EXE, and then read that using the <vi.lib>\Platform\fileVersionInfo.llb\FileVersionInfo.vi

 

The best semi-solution I have for this I posted here.

 

http://forums.ni.com/t5/LabVIEW/Pre-Build-EXE-and-Installer-Set-Version/td-p/3149028

 

Basically it has a pre-build that sets the version, then makes sure any installers have the same version, then aborts the built, and instructs the user to perform the build again.  This second build uses the new build information we just set.

 

I tried invoking a new build but couldn't get the dialogs the way I wanted and it would sometimes show an error.

[ShaunR]

Having a string constant on the BD that gets updated is just another way of showing a version which might not match.  For this reason I'd really rather just maintain the version with the EXE, and then read that using the <vi.lib>\Platform\fileVersionInfo.llb\FileVersionInfo.vi

 

A BD constant is cross platform; FileVersionInfo.vi isn't.

[joerghampel]

I agree that the version information should be (at least also) stored in the .exe file properties, that's what I do as well.

 

But: There is a good reason to store version info on the block diagram. Everybody can identify the version of the VI itself, not the executable, even if it's not under version control any more. I do have customers that don't use their own version control system, and I have no internet access to use mine. So, what I ended up with, is generating an .exe with my build script at the end of the work day, writing the version info also to the readme textfile (which might or might not get lost down the road) and to the block diagram of the main VI. Then I copy everything, take it home with me, and put it in my own version control system.

[hooovahh]

My customers have no interest in cross platform-ability.  They do care for standardization, and they know how to find the version of an EXE without running it.  They also know how to look up what version of the installer was installed by going to Add Remove Programs.  If those don't match it throws up red flags for them.

 

If my customer site doesn't have internet I bring along a 4G USB device with my laptop.  That being said I haven't been to a customer site that didn't have internet in quite a while.

 

Tracking what version of source was used in an EXE also tells you what version of the VI was used in that EXE.  When coupled with SCC, this gives so much more history and diff management. I just see it as another thing to manage when SCC does it for you.

[joerghampel]

I agree with everything you write, hoovah. But ;-)

 

Customers tend to copy directories and store and reuse projects from time to time. I don't see any reliable way to clearly identify one VI outside of version control other than writing some kind of identifier or history to the VI (be it block diagram, VI properties, front panel, whatever).

[ShaunR]

My customers have no interest in cross platform-ability.

 

I think you miss the point. The filversioninfo is windows only so it won't work with things like CRIOs running NI Linux Real-Time or VxWorks. How do you version control your FPGA code, for instance? I'm not even sure if it would work with NI ETS but it might-I'm sure someone will clarify that. Your customers' preferences are only one aspect to x-platform.

Edited July 6, 2015 by ShaunR

[joerghampel]

Good point, Shaun.

 

In fact, SingleBoard-RIOs made me think about generating a readme file, so that I could easily find out about the version of the application when connecting only via FTP.

[hooovahh]

Customers tend to copy directories and store and reuse projects from time to time. I don't see any reliable way to clearly identify one VI outside of version control other than writing some kind of identifier or history to the VI (be it block diagram, VI properties, front panel, whatever).

Okay point taken.  But in this case I'd just make it clear that modifying source code without SCC is not recommended, which is true for all development.

 

How do you version control your FPGA code, for instance?

Currently the same way, and EXE is built for Windows, which includes the bit file needed for the FPGA, which links back to the commit version.  EXE version 1.0.1.293 is commit 293 which is the master commit for the project which includes all source needed including FPGA.  I guess the day that I have a project which has no Windows built EXE in it, I'll need to try something else, but again never has that been the case for me.

[ShaunR]

Currently the same way, and EXE is built for Windows, which includes the bit file needed for the FPGA, which links back to the commit version.  EXE version 1.0.1.293 is commit 293 which is the master commit for the project which includes all source needed including FPGA.  I guess the day that I have a project which has no Windows built EXE in it, I'll need to try something else, but again never has that been the case for me.

 

I give up It's kind of like the Linux fan-boys that answer "install Linux" to every Windows programmers' questions about compiling.