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