Always use the app package version and not app version to your package versioning

Written by Alex Marin · April 15th, 2020

Every software packaging department has its own rules when it comes to MSI - whether we talk about naming convention (package naming, product naming) or package description and comments.

This article focuses on understanding the importance of using the package version and not the app version, when changing the ProductVersion of a repackaged app.

The standard applies to vendor MSI’s too. And, as a general rule in the industry, no changes should be performed to ProductName, ProductVersion, ProductCode, UpgradeCode.

One of the most common and misunderstood concepts, when changing the ProductVersion of a repackaged app, is using the application version instead of the package version.

Application Packaging Best Practices - Package Semantic Versioning

Application versioning is the process to assign unique version numbers to keep track of developments of a software product. Version number conventions increase order and have the format “major versions.minor version.patch version.build version”.

Here is an example of versioning for Advanced Installer latest versions:

The same rules of versioning strategy apply to the software packages.

Application versioning and package versioning of the given application are not interconnected by reciprocal causality so when a software package increases its version numbers it does not trigger/increase in the application version.

A software package, on top of/additional to the actual application, contains the installation logic which is composed of sequences.

Additional elements as Environment Variables, INI Files, Task Schedules, or Custom Actions, which alter the installation or uninstallation sequence of a package, can be added in order to prepare the system for the application.

On the vendor side, when development is confident that the application is ready for a version release, all they have to do is build the installer itself.

Additional alterations or improvements on the package might be needed after release, but they don’t require changes in the application code. The package can be altered independently and it’s product version increased accordingly.

However, since the software package is the only one altered, the software developer input is not needed as the software version does not need to be changed.

The ProductVersion is not the same as the application version, it is the version of the actual installer that is shipped.

How to choose the right version for repackaging

Always keep the original package version number for your packaging versioning. You can use the name of your package to keep track of your package versions.

There is an unfortunate common practice when choosing the version during repackaging, to get the application version from the main executable Help-About menu.

And if the application does not have an About menu -- to get the version mentioned in Properties when right-clicking the main executable.

With time, many vendors started to follow a standard by mentioning the same version in the application and in the package.

But there are several cases when the two versions differ. If the versions differ, you should use the package version and there are a few reasons why.

Let me walk you through the process of reasoning the choice of the package version by answering some simple questions.

1. How do you find the main executable of an application-suite?

Let’s take the Office suite as an example. As you know, it is composed of multiple applications executables like Word, Exel, PowerPoint, and so on.

This applies to all applications which are bundled as suites and offer many features.

So, in this case, what do we consider being the main executable in order to make our version reference. Challenging, right?

In my experience, I found that there are applications with a main executable. In this situation, the following question arises.

2. How do you address the application lifecycle in your packaging versioning procedure?

The application lifecycle is one major topic in the modern infrastructure world. This results into constantly updating all the applications.

In order to maintain the application lifecycle, reports are extracted constantly from the database. What if the application has one package version on the vendor website, and the package which is released into the infrastructure has a different one, who can tell the difference on which package is which?

For example, an application with version 1.0.2 is released on the vendor website and it’s repackaged in the infrastructure with version 1.0.1.312.

I recommend never to use this versioning logic - respect/comply with vendor’s packaging version number and use the name of your software package to keep track of your package version.

During a software audit process or if the customer asks for a report on how many people have version 1.0.2 installed on the machines, how do you?

How do you explain the difference between the versions?

3. What if there is a need for vendor support in cases of unwanted application behavior?

There are many situations when the vendor support is needed for an application.

Usually, the relationship with the support service is handled by the customer’s technical representative.

And, if we take the previous versioning example, the vendor probably won’t know what package version the customer refers to because it was changed during the repackaging process.

4. How to prevent new employees from falling for diving away from the application version?

In modern times, application packagers are constantly changing jobs from one company to another.

The application lifecycle is an application packagers’ job and each packager must have a clear picture of the end-to-end packaging process internal standards, starting from the moment the packaging request is raised until the packaged application is not needed anymore and it must be decommissioned.

If you employ new people and skip the onboard you risk mistakes in reporting, customer support, updates, downgrades, and many other problems.

In the end, the packager will not have a clear picture of what is happening in the infrastructure, and all the documentation which is present on a vendor website is useless.

Conclusion

While cases with differences between the app version and package version are the exception these days, when one exception of the rule is found, the best way to handle it is to use the package version and try to keep every detail as close to the vendor setup as possible.

This reduces issues in the infrastructure and makes it easier for the technical team to manage applications.