Question about upgrades and patches

[DLee65]

I am in discussions with management concerning providing upgrades and patches for a product that we have already released. The setup type is Basic MSI and the Upgrade table has been authored correctly in the original release. The path for upgrades though is a bit confusing to me.

Here is the chronological order that management wants things to happen

Gold Release 9.00.0000

SP1 Remaster 9.02.0000 - should be a major upgrade and want to force complete uninstall of previous edition.

SP1 Patch 9.01.0000 - should be minor upgrade, data is excluded from patch due to size. Should not overwrite SP1 Remaster.

Hypothetical future maintenance:
SP2 Remaster 9.04.0000 - should upgrade all previous versions.

SP2 Patch 9.03.0000 - should provide update without data files from 9.00 to 9.02 including the SP1 Remaster and Patch.

So my question: Is this type of upgrade path possible? If so how do I handle the changed ProductCode in SP1 Remaster and SP2 Remaster with the patches. Can a minor upgrade be applied to more than one product code?

Hopefully someone can provide some quick guidance on this as I have a meeting in an hour about this. 😄

[MichaelU]

Trying to squeeze in a quick answer, if I understand this you've got A minor/patch to B major upgrade to C, then want to distribute D as a minor/patch from A B and C, it's not possible as it would have to be a major upgrade to either A and B, or to C. Technically it's possible to package a major upgrade as a patch, but it's not worth the effort, and the constraints are tighter than minor upgrades.

[DLee65]

Thanks. That has been my understanding of the situation as well. Another problematic item is that they want to release the Remaster 1 first - which is a major upgrade. A month later they want to release a patch to download which is a smaller subset of the Remaster 1 (not sure why they have a delay in this). Of course the patch is a minor upgrade so no change in ProductCode.

I guess the path to Remaster 1 would be easy enough, it when we get into Remaster 2 and stuff that gets tougher.

[MichaelU]

Releasing the first patch after the first major upgrade is a little bizarre. But the problem comes with trying to target both sides of a major upgrade in a single patch. Assuming that you want to keep the major upgrades as planned, the options I see for the patch targeting a single major revision range:

• Release, say, a 9.01.1234 that upgrades both 9.00.0000 and 9.01.0000 (but does not apply to 9.02.0000 or later), and a 9.03.1234 patch which targets 9.02.0000 and 9.03.0000 (the 9.03.0000 patch only targets 9.02.0000), or
  
• Cut your test matrices and skip the lower revision patch once the higher revision one is available, so perhaps release 9.0, 9.2 Major, 9.1 (Patches 9.0), 9.4 Major (obsoletes versions before 9.2), 9.3 (Patches 9.2; 9.0 and 9.1 are obsolete), etc.
  

Alternately, you could release full packages, giving you a minor upgrade from the current major revision and a major upgrade from the previous. It doesn't cut the size of what you distribute, but it does cut down the changes to the machine within the same major revision. It would also (like the patch) refuse to install on a later major revision so you couldn't put 9.1 on top of 9.2.

[#5]

The real sticky point for this patching scenario is that it breaks once you change the Product Code. Once you've gone over this ledge, the upgrade path is chosen for you.

Regardless of how you design your patches, you're going to have differing Product Codes resulting in a Major Upgrade patch and a nightmare for maintenance.

The other thing I'm thinking is whether you have a situation to justify the major upgrade scenario. If the patch is capable of upgrading 9.00 -> 9.01, which is a subset of 9.02's files, you can't be doing a major upgrade without violating fundamental Windows Installer component authoring rules.

Keep in mind that Component Authoring rules must still be followed when designing your application or you will experience oddities related to component removal (http://msdn2.microsoft.com/en-us/library/aa370561(VS.85).aspx). Specifically:

Never create two components that install a resource under the same name and target location. If a resource must be duplicated in multiple components, change its name or target location in each component. This rule should be applied across applications, products, product versions, and companies.
Note that the previous rule means that two components must not have the same key path file. The key path value points to a particular file or folder belonging to the component that the installer uses to detect the component. If two components had the same key path file, the installer would be unable to distinguish which component is installed. Two components however may share a key path folder.
Do not create a version of a component that is incompatible with all previous versions of the component. This rule should be applied across applications, products, product versions, and companies.

In essence, those rules create a mutually exclusive situation. Either you're deploying a patch as a minor upgrade and thus the major upgrade is not necessary or you're deploying a major upgrade and the minor upgrade is going to violate component authoring rules.

My opinion is that you should consider whether it's actually necessary to perform a major upgrade and perhaps that may simplify your upgrade strategy.