Versioning DLLs and EXEs

[chris128]

So we all know that it is good practice to break your code into reusable chunks and keep them in class libraries (DLLs) - however we of course still need an executable file (EXE) to actually run this code. So the EXE is the main part of the program from a user's perspective as it usually contains the user interface, but the DLLs can actually contain the core application code.

So... if I update the code in a DLL that my EXE uses, and this is a major part of how the application works, should I just increment the DLL file's version number or should I also increment the EXE's version number? If I update the EXE as well (so that if the user went to Help -> About, then it would show them a newer version number), then should I increment the EXE version number every time I update any DLL that the program uses or should it just be the 'main' ones? It makes sense to me not to increase the EXE version just because a DLL has been changed but this then means that the user has no way of knowing if their application is using updated code or is still on an older version. The problem then though is that if all of my actual logic code is in DLLs and the EXE is basically just a "shell" to execute the functions in the DLLs, then the EXE version would never increase even if the way the application did its work had completely changed.

The best way of doing this as far as I can see is to do this: instead of just showing the user a single version number in the Help -> About dialog, I would have a list of the core DLLs and display their version numbers as well. However, I do not recall ever seeing an application do this, so there must be a more standard approach to calculating the version number of a program...

What do you guys do?

Cheers
Chris

[dilettante]

You might do a number of things, but I tend to try to "go with the flow" and stick with the two-number system users see most often. I use Major.Minor for versioning software as a package.

As for the other two numbers I tend to ignore the "third" one (Build) that VB6 doesn't support directly anyway, and use the 4th one Revision to identify how many changes have occurred to an individual component. This is consistent with VB6's Auto Increment feature as well.

So I have package releases where each piece is numbered 2.3 across the board even though the EXE may be 2.3.0.34 and a DLL might be 2.3.0.12 instead.

The Revision is more a value I use for specific identification in my Change History for each component. It is also useful when diagnosing a customer-reported failure. I never reset Revision to 0 except in rare cases like a major rewrite, and this always involves incrementing the Major value.

To be clear about this: when Major is incremented I do not set Revision to zero automatically, but if I reset Revision to zero I always increment Major and set Minor back to zero:

Last version               EXE: 1.5.0.315  DLL: 1.5.0.28
Next version               EXE: 1.6.0.318  DLL: 1.6.0.29
New version, major rewrite EXE: 2.0.0.319  DLL: 2.0.0.37
                  or maybe EXE: 2.0.0.0    DLL: 2.0.0.0

In places like a main Form Caption, etc. I just report Major.Minor. In places like an About dialog I usually report the EXE version as Major.Minor.0.Revision, and in readme.txt files and such I may report the full thing for each component when I list the files installed by the release package.

Every time anything is published, shipped, etc. (released into the wild) it gets a new Major.Minor combination. The exception might be a "hot fix" where I ship a standalone replacement DLL, etc. where only Revision is updated.


Places like About dialogs don't usually need a full roster of the versions of each component. There may be exceptions to this, but usually that is when one of the components is a shared OCX/DLL I want to track, since it may have been updated by some other product's installation.

For my own code I don't need this because I always put out new Major.Minor on everything (again the rare hot fix can change this).


You might look at http://en.wikipedia.org/wiki/Software_versioning as well.

[chris128]

Thanks for the response, I think I get what you mean but just going to have another read of your post (and that link) to make sure I fully understand

[techgnome]

at my last job, we versioned both the DLLs and the EXE. This was so that we could support multiple clients, who might be on the same major version, but different builds, or one the same build, but different versions. when we'd issue them patches, the exe versions wouldn't change, but the DLL ones would. When we then issued the quarterly releases, then everything gets updated. This way, when they have a problem with a particular section of the app, we know what version of the dlls they are on, and if it was fixed already.

Where I work now, it's a little different as we are completely internal. So everytime we do a release, all we update is the Application Version, even if it's one DLL that is being updated or a dozen.

In the end, I'm not sure that it matters, as long as it is applied consistently.

-tg