Should executables contain version numbers in their names?

Question

I develop a certain server. Till now, two versions could not be installed at the same time. We're now changing that, and the question came up: should the version number be appended to the server components or not? The server contains 3 exes and 5 dlls (some COM, some native VC++). Should any or all have their name contain the version (Serv71.exe, module71.dll) or not?

On the pros side, it should make managing the server a bit easier. If a certain instance misbehaves it would be identifiable in the task manager. Also, there's no chance a bad installation will end with having mixed components versions without it being noticed.

On the cons side, it would make development a bit harder. The server is not a standalone product, but rather a part of our applications infrastructure. This means it gets the main app's version. That given, a certain component will have to get a different name even if it hasn't changed at all between versions.

All in all, this is not a crucial issue. We can probably get along with both ways. Having that said, I might have missed a winner argument in favor of one of the strategies. What is the common choice? what do you do?

Edit: I'm familiar with COM and file metadata versioning, and agree filename versioning is redundant. I'm trying to figure out what's more significant - the constant redundancy overhead, or the rare gain in maintenance.

Answer 1

I'd say if the DLLs provide different APIs in different versions, the version number should be appended to the filename. For executables it doesn't matter. If the executable interact using a specified interface, and that changes, I'd also use the version number in the filenames of the executables.

Answer 2

"On the cons side, it would make development a bit harder."

Not completely true. It exposes an problem you already have -- keeping all the releases of all the components aligned.

You have to make sure that the applications infrastructure as a whole has all the proper releases of all of the components.

Make this easier by properly labeling each piece, and providing a configuration report that says which versions are current and which versions must be used together.

Answer 3

Usually version information is part of the meta data (file extended information) of the DLL and not part of the file name.

The process of maintenance is easier. Setup programs know how to work with that info when you upgrade/replace an exisiting binary file. If you need to issue a new version of the DLL, you dont need to recompile/relink your exe.

As a general guideline -- don't try to invent new mechanisms. Use existing ones.

Answer 4

For COM API's, you really have all the versioning information you need in your libraries. I'd find naming those DLL's with version numbers redundant at best, confusing at worst (at least if version numbers get out of synch). I favour appending a version identifier to interface and coclass names whenever I want a clear upgrade path and anticpate any changes.

For plain binary DLL API's, appending version numbers is an idea, but not one I've ever seeen well executed (and quite terribly executed in those old 16 bit VB runtime DLL's!). Do they have clear and delimited API's, or do they expose dozens of functions? You're going to have problems distingushing a minor from a breaking change if the interfaces are large. Once you start labelling versions this way, you're going to have to be consistent. Every version change will mean that statically linking clients have to be recompiled (and hence version relabelled themselves). The potential problem here is that you get a lot of 'version noise', hiding the important changes.

Windows binaries contain version metadata (the VERSIONINFO structure). As LeJeune says, that's a well-known route, albeit one that deosn't automatically cause errors when you link the wrong stuff together. However, it's one you can relatively easily leverage to support whatever configuration management schema you need.