3.3 Version or Patch Upgrade?
When upgrading an Application you will need to consider whether you should do this as a Version (MSI file) or a Patch (MSP file) upgrade. Before making this decision it is important to understand how these respective files will be processed by Windows Installer.
In essence, Windows Installer will process a Version upgrade as a full installation rather than a patch. If an earlier version of the Application is located on the target system Windows Installer will uninstall the older version before installing the new version. If an earlier version of the Application cannot be located on the target system Windows Installer will proceed as if this is a first time install of the Application.
In contrast, Windows Installer will process a Patch upgrade by first determining the version of the application is eligible to receive the patch. If the application is eligible to be upgraded the changes contained in the patch are applied over the top of the existing application. The main advantage of a patch install over a version install is that a patch only contains changes to your application and therefore is usually much smaller.
Patches are typically designed to be uninstallable. Database changes may be complex to manage and thus are usually delivered by a Version upgrade. Database changes are particularly complex when uninstalling. Firstly, only one user of a database must uninstall the database changes. So, database changes are NOT backed-out automatically, you must specifically request it. Secondly, the standard uninstall processing provided by Windows Programs and Features does not provide a user interface, so you cannot request that database changes be backed out. You must use the command line instead.
By default a patch will not uninstall database changes. To do so or not to do so is a complex subject. If a Patch contains database changes you must fully inform your administrators how to back out the patch, or disable patch uninstall in the Deployment Tool package.
In order to uninstall database changes, misexec must be executed from the command line:
For example:
msiexec /package C:\DEV\TRUNK\WORK\X_WIN95\X_LANSA\X_APPS\PATCHDB\PATCHDB_v2.0.0_en-us.msi /uninstall C:\DEV\TRUNK\WORK\X_WIN95\X_LANSA\X_APPS\PATCHDB\PATCHDB_v2.0.0.5_en-us.msp SUDB=1 /qb
The parameters SUDB=1 /qb are optional. If they are not specified a dialog will be displayed and you can manually check Setup DB on.
Note, these are the functional steps. You must fully consider your specific situation before rolling back database changes. If a database is shared, only one of the users should rollback the database changes. All the rest perform the default uninstall of the patch from Programs & Features.
Alternatively, to back-out a Patch which contains database changes, another Patch would need to be created to restore the database objects back to their original state.
Reasons to consider using a Version upgrade:
- Name of the Application has been changed
- Requirements to allow users to have parallel installations of the Application, with earlier versions and latest version on the same system
- Major change to functionality in Application since last version release
- Major upgrade of LANSA applied since last version release
- Need to install latest version as fully functioning Application
- Modifications to software include database changes.
Reasons to consider using a Patch upgrade:
- Provide enhancements to existing functionality
- Provide new functionality (excluding database changes)
- Changing, removing or adding shortcuts
- Agile development requiring frequent deployment of a small set of changes
- Apply bug fixes to rectify problems with your application.
Note: Patch install and uninstall use the logic in the Version install. Thus, new features for a Patch added in a LANSA release require a new Package Version to be deployed first before you can use the new LANSA features to patch your application.
This also means that patching Versions created with a previous version of LANSA may not work correctly as the Patch code may not be compatible with the Version code. It is therefore highly recommended to NOT upgrade the LANSA configuration which built the Version. What you need to do is to retain a separate Build Configuration for each Version of LANSA which you need to support in the field.
If your application will retain users on both LANSA Version 13.0 and 13.1 for example, then you will need to retain a Configuration for both 13.0 and 13.1. This is good practice anyway, to ensure that as little as possible changes between different releases of your application. Of course you can insist that all users upgrade to the latest Version of your application if they want to receive updates. Then you need only maintain the one Build Configuration.