Leaderboard

Nice try, NSA.

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 applicationWrite 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 distributionAppend 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.

It's not an upgrade code but a Product ID. Technically it is a GUID (globally unique identifier). It is virtually guaranteed to be different each time a new one is generated. This Product ID is stored inside the Build Spec for your executable. If you create a new Build Spec this product ID is each time newly generated. If you clone a Build Spec, the Product ID is cloned too. The Installer stores the Product ID in the registry and when installing a new product it will search for that Product ID and if it finds it it will consider the current install to be the same product. It then checks the version and if the new version is newer than the already installed version, it will proceed to install over the existing application. Otherwise it silently skips the installation of that product. Now, please forgive me but your approach of cloning Build Specs to make a new version is most likely useless. As you create a new version of your application you usually do that because you changed some functionality of your code. But even though your old build spec is retained, it still points to the VIs on disk as they are now, most likely having been overwritten by your last changes. So even if you go back and launch an older build spec, you most likely will build the new code (or maybe a mix of new and old code, which has even more interesting effects to debug) with the only change being that it claims to be an older version. The best way to maintain a history of older versions is to use proper source code control. That way you always use the same build spec for each version (with modifications as needed for your new version), but if you need to, you can always go back to an earlier version of your app. A poor mans solution is to copy the ENTIRE source tree including project file and what else for each new version. I did that before using proper source code control, also zipping the entire source tree up but while it is a solution, it is pretty wasteful and cumbersom. Here again, you don't create a new Build Spec for each version but rather keep the original Build Spec in your project.