The previous section discussed some of the common problems with naming conventions for software. If you remember only two elements of that section, remember that popular software products will be often sold between manufacturers so listing a software library in nested groups by vendors is an unmanagable approach.
The second truth to be aware of is that we still have a 260 character path limitation in many elements of Windows. We have to be conscious about reducing names to the bare minimum of what's required otherwise it wont be possible to use packagenames on UNC based directory shares.
In my experience, the best package names I have seen are in the format of:
<Application Name> - <Optional Differentiator> _ <Version> _ <Architecture> _ <Revision>
eg.
AccessDatabaseEngine_14.00_64a
AccessDatabaseEngine_14.00_86a
ActivePerl_05.08_86a
Adminstudio_11.00_86a
ApplicationVirtualizationDesktopClient_04.06_64a
ApplicationVirtualizationDesktopClient_04.06_86a
ApplicationVirtualizationSequencer_04.06_64a
ApplicationVirtualizationSequencer_04.06_86a
Project-Professional_14.00_64a
Project-Standard_14.00_86a
Field Definition
<Application Name>
The appliction name can normally be retrieved directly from a Vendor MSI. Wherever possible manufacturer names will not be included in this field. This is surprisingly effective in ensuring that packages are unique as software is trademarked and duplicate application names are relatively uncommon when abbreviations aren't used.
<Optional Differentiator>
There will be occassional requirements for different configurations of the same package. Examples may be regional or site based differences for the same software, language differences, license differences etc.
<Version>
It is worth looking at the actual specifics behind the fields for version of Windows installer. Due to the character limitations ith Windows it's not possible to use the full version. I've seen organisations that use the major version field (such as version 1,2,3,4 etc)... it works really badly as organisations can have requirements for (as an example) both version 4 and version 4.5 of applications at the same time. Requiring Major and Minor version fields is a workable standard (XX.XX).
<Architecture>
Software must be differentiated between different architecture versions of the same product.
<Revision>
As bugs are fixed in a production package the software must reflect revision changes. Most commonly revisions seem to be represented by a three digit numeric representation such as "_001" or "_002". A more intelligent approach is to use an alphabetic character (a,b,c etc) as it reduces the number of charcters required in the overall package name string.
- Log in to post comments