Software Versioning Suggestion

[viSci]

I would like to settle on a consistent version management method that will give me basic version numbering on the software components in my system.

I have 3 types of HMI (windows) and 2 flavors of cRIO code. I would like to have one global software version embedded in each exe so that it can be locally and remotely verified.

The problem I have is how to reconcile all the different version numbers that exist such as the SVN revision, the LV build revision, LV VI revisions and now

an additional project based version vi that I am starting to include for all builds.

I was hoping to hear from others who have navigated these waters before and might

have some tips to offer.

[Tim Erickson]

Here are a couple of suggestions:

1) Create an About VI that has a version number embedded in it. When called it supplies a version number. It would have to be updated when you update your application.

2) Put a version number in a configuration file that can be either opened manually or retrieved using a VI.

3) You can enter a version number in a built exe.

4) You can enter a version number in an installer.

5) Put the version number in a Help\About pull down menu choice (in the case of an HMI)

6) Use the revision number in the title bar of the top level VI.

[jdunham]

I would like to settle on a consistent version management method that will give me basic version numbering on the software components in my system.

I have 3 types of HMI (windows) and 2 flavors of cRIO code. I would like to have one global software version embedded in each exe so that it can be locally and remotely verified.

The problem I have is how to reconcile all the different version numbers that exist such as the SVN revision, the LV build revision, LV VI revisions and now

an additional project based version vi that I am starting to include for all builds.

I was hoping to hear from others who have navigated these waters before and might

have some tips to offer.

Our numbering system is major.minor.build.svn.

Every build has a unique tuple of major.minor.build, and that's how we refer to the releases. We try to build all our exes at the same time with a script, so there may be several related EXE's with the same version number, but they have different names and installers.

The last number is the SVN revision of the source code repository version from which the EXEs were built. SVN uses a global numbering scheme which always increases. This makes the code traceable.

We also steal a page from Linux where odd minor releases are developmental, so 5.3.152.20534 (we'd call it 5.3.152) is yet another test build, whereas 5.4.3.25787 is a release candidate (denoted by "4" being an even number).

We ignore the VI revisions.

Edited December 7, 2010 by jdunham

[jdunham]

Also, LabVIEW ships with this VI:

<vi.lib>\Platform\fileVersionInfo.llb\FileVersionInfo.vi

which will dig the version number out of your EXE file (it's the same info that you get when right-clicking on the file in Windows Explorer).

That's what you should be displaying in your about box etc., rather than some global variable that you save before building.

Also you can use property nodes to make sure the EXEs and the Installers have the same version numbers.

Edited December 7, 2010 by jdunham

[ShaunR]

I use a very simple versioning system.

Internally (i.e not releases) it's Major.Minor.Revision.Branch.Increment.

For releases its Major.Minor.Revision only (svn is up-issued to the release version x.x.x.0.0 at the same time). The emphasis (from left to right) is "From features to bug fixes".

Major = Major functional changes/feature additions (adding OS support, lots of new features/changes, well, anything major really ).

Minor = Small functional changes (bug fixes, changes to existing features and maybe a new feature or two.

Revision = Bug fix only release.

The aim is to only have Major and Minor releases

Of course, there is a big subjective grey area in deciding how many changes/features etc warrants a major or minor increment but roughly above 20% increase in code base or over 40% of the code base affected by any changes would definitely be considered major..

Edited December 7, 2010 by ShaunR

[viSci]

Yes, I had thought about using the FileVersionInfo.vi but it appears that this information does exist in the cRIO (VxWorks) file system.

Actually, I wonder why NI does not build this into all exe's with a native property node to read it out.

Also you can use property nodes to make sure the EXEs and the Installers have the same version numbers

Could you tell me what property nodes you are referring to?

[jgcode]

Also you can use property nodes to make sure the EXEs and the Installers have the same version numbers.

I would lean towards build scripts to update the version numbers of exe and installers and synch with SCC.

Unfortunately (as of LabVIEW 2009 anyways) Real Time targets do not have a version field (and I think they should) in their exe's.

I would only do this if the release was monolithic, i.e. you had to do a build of everything at the same time.

Sometimes its not practical to e.g. update RT code just to synch the version (if the client has the target out in the field), when you only have to provide an update to a HMI etc.

[Ton Plomp]

Also, LabVIEW ships with this VI:

<vi.lib>\Platform\fileVersionInfo.llb\FileVersionInfo.vi

which will dig the version number out of your EXE file (it's the same info that you get when right-clicking on the file in Windows Explorer).

That's what you should be displaying in your about box etc., rather than some global variable that you save before building.

Also you can use property nodes to make sure the EXEs and the Installers have the same version numbers.

Here's a little snippet on how you can use this code:

Ton

[Daklu]

We also steal a page from Linux where odd minor releases are developmental, so 5.3.152.20534 (we'd call it 5.3.152) is yet another test build, whereas 5.4.3.25787 is a release candidate (denoted by "4" being an even number).

I like to do this too. One thing I haven't figured out is how number a test build for a new major release. I'd like the released build to be version 5.0.0, but then I run into the irritating mathematical property that any version number less than 5.0.0 is part of the version number set defined by 4.x.y, which defeats the purpose of using the major version number. How do you deal with that?

(Idle thought... I wonder how a negative minor version number would affect the many tools we use...)

[jgcode]

I like to do this too. One thing I haven't figured out is how number a test build for a new major release. I'd like the released build to be version 5.0.0, but then I run into the irritating mathematical property that any version number less than 5.0.0 is part of the version number set defined by 4.x.y, which defeats the purpose of using the major version number. How do you deal with that?

I guess that is why the build number can be important.

E.g Test App: 5.0.0.123; RTM App: 5.0.0.234.

Your new App is of the 5.0.0 version and the build number can either be transparent to your clients or included (whatever is preferred).

But your comparison logic will not fail.

[jdunham]

Here's a little snippet on how you can use this code:

I think he was referring to programmatic setting of version numbers in the build specs. Basically you have to open the Project Reference, the Target reference, and drill down to the EXE Build Spec references, and then use the Set Tag method to change the TgtF_fileVersion.major, .minor, .patch, .build properties. For the Installer build spec, the tag is called INST_productVersion, and it takes a string of the format "1.2.3", whereas the EXE tags take integers. Oh, and in LV2009 and earlier, the tags were called App_fileVersion.* for EXEs, and ProductVersion for Installers. So I have some spaghetti code which handles this, but I'd rather try to make a real version before releasing it. You might have an easier time writing software to edit the lvproj file's XML contents directly. With LabVIEW's regular expression search and replace you could do this easily.

I like to do this too. One thing I haven't figured out is how number a test build for a new major release. I'd like the released build to be version 5.0.0, but then I run into the irritating mathematical property that any version number less than 5.0.0 is part of the version number set defined by 4.x.y, which defeats the purpose of using the major version number. How do you deal with that?

Personally I would use 4.9.x for the development builds leading up to 5.0. It certainly suffers the defects you mention, but you can always write a VI that checks version numbers and treats an x.9.x version as an x+1.0 version. Also we try hard to minimize version-specific behavior.

I guess that is why the build number can be important.

E.g Test App: 5.0.0.123; RTM App: 5.0.0.234.

Your new App is of the 5.0.0 version and the build number can either be transparent to your clients or included (whatever is preferred).

But your comparison logic will not fail.

We immediately went away from this approach. In conversation (which is important), and more importantly in bug reports, people are going to say "5.0.0" rather than "5.0.0.6485", so it's important that "5.0.0" refer to a very specific, traceable piece of source code and executable. We've taken some pains to make sure our build system can't produce two successful builds with the same first three numbers.

[Black Pearl]

Everyone still on SVN?

Using Hg, you get a GUID (4 words Hex), that identifies the code (a branch in any repo somewhere). Thats more acccurate in a branching enviornment than the current rev.

And then just make the 5.0 a shining decoration without real meaning.

Felix

[jdunham]

Everyone still on SVN?

Using Hg, you get a GUID (4 words Hex), that identifies the code (a branch in any repo somewhere). Thats more acccurate in a branching enviornment than the current rev.

And then just make the 5.0 a shining decoration without real meaning.

I checked out Hg. So what it if it's easier to branch and merge; the difficulty of the merge remains in diffing LabVIEW routines, which sux. SVN is working fine for our small team.

I agree that the SVN revision number must be coupled with a URL for true traceability. But that should be kept in your build logs, not exposed to the end user.

If you get a bug report by phone, and you ask for the version they are running, is it better to hear "5.0.3.64572", or "5.0 (EB63908A-031A-11E0-BEAA-C410DFD72085)"?

[jgcode]

E.g Test App: 5.0.0.123; RTM App: 5.0.0.234.

...build number can either be transparent to your clients....

We immediately went away from this approach. In conversation (which is important), and more importantly in bug reports, people are going to say "5.0.0" rather than "5.0.0.6485", so it's important that "5.0.0" refer to a very specific, traceable piece of source code and executable. We've taken some pains to make sure our build system can't produce two successful builds with the same first three numbers.

So tying back to Dave's question, are you saying that you prefer to jump versions of releases to clients e.g. 5.0.0 (rtm), 5.0.1 (internal test), 5.0.2 (internal test), 5.0.3 (internal test), 5.0.4 (rtm) etc.... ? I agree with what you are saying (I think), but if you need to e.g. perform regular (e.g. nightly) builds, but still release then "next version" e.g. 5.0.1 to 5.0.2, then build numbers seem logical?

I agree that the SVN revision number must be coupled with a URL for true traceability.

(I don't use SVN) But wouldn't using a label (tag) be a good idea?

[jdunham]

So tying back to Dave's question, are you saying that you prefer to jump versions of releases to clients e.g. 5.0.0 (rtm), 5.0.1 (internal test), 5.0.2 (internal test), 5.0.3 (internal test), 5.0.4 (rtm) etc.... ?

For us, all minor releases (second number) with an even number go to the QE guy. If 5.0.4 passes his tests, he's authorized to release it. By the time it gets to that point, we should already be building 5.1.x regularly and getting it ready. 5.0.x builds are built off a branch which is frozen except for fixes. 5.1.x is getting built off the trunk. Once we are feature-complete and start building 5.2.x, it's quite possible we'll need to patch an old version. So it's no problem to build 5.0.5 too, off of the 5.0 source branch, at the same time as we are working on later versions.

(I don't use SVN) But wouldn't using a label (tag) be a good idea?

Not exactly sure what you mean. We do tag the source from every build, but it's redundant. If you have the source code URL and a version number, you have a traceable copy of what was built. Again this is not visible to the end user. The requirement is that the user can submit a bug report with the contents of the About window, and I can check out the exact copy of the source code.

I may have answered part of this above. In SVN tags and branches are the same thing, but there is a convention that you don't commit any more code into a tag. So we have branches for all releases, 5.0, 5.2, 5.4, 6.0 (the numbers have been changed to protect the guilty). The odd number releases (5.3, 6.1) can be built out of any branch, either the trunk or some experimental branch, but during acceptance testing and for patches after release, the even numbered branches should always be built from the feature-frozen release branch.

The least enforceable part is to actually freeze the release branch, but we do the best we can. The more you add features to a release branch, the more work you have to do to merge it back into the trunk (which for us is the everyday development code).

Hope that helps,

Jason

[jgcode]

In SVN tags and branches are the same thing,

I thought the terminology was different - i.e. a tag being a bookmark of code (revisions), and branch being actually code?

But like I said I don't use SVN (only dabled with it wrt SF).

In Perforce bookmarks are called labels, branches are branches.

[jdunham]

I thought the terminology was different - i.e. a tag being a bookmark of code (revisions), and branch being actually code?

But like I said I don't use SVN (only dabled with it wrt SF).

In Perforce bookmarks are called labels, branches are branches.

Right. It's a peculiarity of SVN that tags and branches are implemented the same way (http://svnbook.red-bean.com/en/1.1/ch04s06.html). At any rate, if you can get a meaningful, traceable tag into the About window, that's great. But my overall recommendation is to keep unique version numbers, and have a system where any version number can be easily traced to a specific snapshot of your code repository.

The system we use, where version 1.4.2.12345 can also be called 1.4.2 for short, and either way can be traced to a specific snapshot and branch of code as well as the 1.4 feature spec, has worked out very well. This also allows us to make a small change and build 1.4.3 on very short notice, though we have learned to keep a virtual machine around with the same version of LabVIEW and the drivers on it, for patching those old versions.

I have to add that all this I've written was learned by screwing it up at one time or another!

Anyway, I hope this helped the OP. We don't build for multiple OS targets, but I don't think that would break this system.

[ShaunR]

What would be nice is for the LV project manager to be able to handle (nest?) multiple projects (the way many other IDEs do). Then we could make a project for each target and add them to a main project. (I know we sort of have this with lvlibs. but it's not quite the same thing). Once we had that, each sub-project would just be a branch off the main svn (or Mercurial if you like ) trunk (main project) and we could work on each target in isolation if we wanted to.

Unless of course we already can and I haven't figured it out yet.