Package Naming Standards

Creating Packaging Standards

Application Packaging standards should be logical, quantifiable and unambiguous.

Standards should ensure that completed packages are:

Named in an easily identifiable format
Auditable on the basis of revisions made
Compliant of Microsoft guidelines
Compliant of Best Practice understanding
Robust
Able to leverage Windows Installer Technology benefits (such as self-heal & Rollback)

When trying to create packaging standards the first standard to set will be the creation of a Naming Standard.

A package naming standard must ensure that completed packages have unique names and can be identified as to which version of an application the package represents.

A naming standard should be tight enough to ensure that different application packagers (or different Information Technology support staff) would create the same package name if they were independently given Vendor Supplied software. When naming standards aren’t tight, multiple versions of the same software start appearing in the environment under different names. I once worked in an organisation that had a package of “Office2000” along with packages for “MSOffice2000” and “Microsoft Office 2000”. Each package has its own bugs and would behave slightly differently on the machines that received it. There should only be one possible name for a package created from Vendor software.

A naming standard will almost always have an internal “release” or “build” component that can identify if bug fixes have been put into an application. This helps to identify that an updated package is not actually a different version of software that has been received from a vendor or developer.

A naming standards document will construct a set of rules for how to determine an application’s internal package name from software supplied from a Vendor. This name will be based on a combination of the vales of:

Application name (as stated by the vendor)
Application version (as stated by the vendor)
An internal “release” or “build” reference number
Target platform architecture (such as x86, x64)

Some organisations will also have in their package name:

Vendor (such as Microsoft, Adobe etc)

Also…

The Naming Standard must also have the ability to have an optional descriptor that can differentiate between packages because of configuration differences This “Optional Identifier” probably won’t be present in all package names but the Naming Standard must allow for this addition if needed.

With anything that is standardised in Information Technology, rules must be defined for omitting special characters and Space characters from derived names.

There must be a degree of freedom for the optional descriptor to allow packages to be identified for a number of different scenarios.

An example would be the package:

AcrobatReader_8.0 Acrobat Reader version 8.0

AcrobatReader_(Fr)_8.0 The “Fr” of “French” designator would be considered an optional identifier

AcrobatReader-Imp_8.0 Or, the “Imp” may be a designator for Imperial measurement.

Package Name Potential Problems

After working for a number of organisations, I’ve seen a number of problems related to Package naming standards. The biggest problems have not been with logical policies but with the limitations of current technology. The most common issues are discussed below.

Package Name Length

The Package name will be used to create directories and paths of servers that hold installation files for the product. We still have to be conscious that Windows Explorer in Windows XP still has problems with directory depth of more than 260 characters.

Organisations that use SMS for software distribution will be aware of a 50 character limitation with reporting on package names with that product as well.

There will be occasions where our package directory holds Administrative installations which will have very deep paths such as:

<PackageName>\[PROGRAMFILES]Vendor\Application\Version\main\Addon\help\ … etc

When this is combined with UNC[1] formatting for locating the package such as:

\\servername.domain.local\share\SoftwareDelivery\CompletedApps\

It can be extremely easy to cross the 260 character directory depth. In this scenario, the only thing that can change is the Package Name. It’s preferable to adopt a Naming Standard that is deliberately short.

Using Variables in the Name that Change

A seemingly good idea can be to include the names of business groups or organisational units in a package name by default. I’ve seen organisations where the completed package contains the name of the organisational unit that sponsored the packaging. This approach tends to go wrong for two major reasons.

1. Packages can’t just be reused by other organisational units without creating a new package with an altered name.

2. Organisational units change their names and are restructured quicker than the expected lifespan of packages.

There are other variations I’ve seen on this problem:

I once worked in a corporation that prefixed the Package Name with “core” if the application was for distribution to all workstations and servers. Once this application is replaced or the environment changes so that it isn’t wanted on all machines at all, the “core” name remains but is completely meaningless.
Another organisation tried to use the string “base” as part of the application names for all applications that were part of a base build. When the application stops being part of the base build, the naming convention would require re-naming the package if the rules were to make any sense.

Using a Vendor name in the Naming Format

Popular software titles are often sold or acquired by different vendors over a period of time. When Vendor names are included as the first part of a string within a package-name it is inevitable that confusion will occur as products get on-sold between manufacturers. Common examples are:

Wise Solutions Wise Package Studio

Altiris Wise Package Studio

Symantec Wise Package Studio ...

Are all the same application but of different versions. The Vendor name being used as a primary identifier is extremely prone to problems in identifying the most up-to-date version of enterprise software. Virtually no shortcuts are every placed in a manufacturers subdirectory off the staff menu so it’s extremely easily for staff to never actually know who develops the products they use on a daily basis.

One of my favourite examples is of the piece of software called SB Client as every few years the software was sold to a different vendor eg.

System Builder - SBClient <version 1.x> (Early 1990’s)

Unidata Corporation – SBClient <version 3.x> (1996)

Ardent Software – SBClient <version 5.0> (1998)

Informix – SBClient (2000) <version 5.2.3>

IBM – SBClient (2005) <version 5.2.4>

Rocket Software – SBClient (2009) <version 5.2.4 – 6.0>

Having manufacturer details as the first characters of a string identifier makes it impossible for suites of products to be grouped together and forces the use of additional administrative processes to identify upgrade paths of products.

I have become convinced that using a Vendor name within the naming format is a mistake that doesn’t provide the benefits that may be initially envisaged.

Target Platform as part of the Application Name

All of the examples of naming problems so far have been with organisational unit names or names that identified packages by their nature as being part of a core build. Increasingly, a headache which is showing itself again and again is the problem of maintaining a meaningful standard while identifying a target platform in the name itself. From what I’ve seen, this has come about with the remote building and managing of servers over recent years.

Typical conventions may append a platform designator to the start of the package name such as:

x86_

x64_

Wks_

Svr_

Part of this issue is due to the relatively basic interface behind the SMS management Console. When a Package is loaded into SMS, the description that may be written about the package is brief. Nor do Deployment Administrators don’t want to have to consult separate databases to see which packages should be deployed in the environment. The solution appears simple that packages “Wks” packages are always used for Workstations and “Svr” packages are used for servers. Very quickly the “simple” standard starts fraying around the edges as some packages can be installed on both Workstation and Server. Some packages are for 64bit and others 32it architectures and again some packages will install on both. When all of these are combined, we quickly loose all standards and end up with a tangled mess.

The situations where a package must be altered to run on a server or must be different because of its architecture can be marked by using an optional identifier in the Package name.

Abbreviations Introducing Variation

Abbreviating application names to commonly used names allows for multiple versions of the same application to be packaged. Abbreviations of “common” names shouldn’t be allowed at all within a Naming Standard.

Non-Programmatic Variables

As diligent information technology workers, we will always try to automate repetitive tasks. This is good for us (because we get bored with repetition), good for our organisation (as it increases output and allows for greater auditing).

[1] Universal Naming Convention