5 replies to this topic

[Tifoid]

I have a question related to having two different packages (with differing package codes) upgrade two differing starting points to the same end point.

The scenario is the following:
Product V0.1 is upgraded by MSI V1.3a to Product V1.3
Product V1.2 is upgraded by MSI V1.3b to Product V1.3
(please note the a/b notation is to denote differing package contents and differing package codes)

Does anyone know if this scenario will cause any weird issues/problems?
Will having 2 differing MSIs upgrade to the same end state (same final version) cause any problems farther down the road?

[Stefan Krueger]

This should work as a Major Upgrade in any case. Or as Minor Update shipped as full .msi if the Feature-Component tree of the two abse packages is similar enough. It should also work a Minor Update Patch (.msp) which basically will create two streams in your patch, one for each base version.

[Tifoid]

Will it work if MSIV1.3a and MSIV1.3b are two completly seperate installers? Basically, we are looking at creating 2 seperate installers to migrate from 2 differing branches back into one. Each installer would be custom to the branch it is coming from but would result in the same end version of the software (in this case Product V1.3).

[Stefan Krueger]

As a Major Upgrade: yes that should work. (Migrating feature states may not make sense if the Feature structure is too different)

[Tifoid]

We were not planning on releasing this as a Major upgrade, just a minor. Do you think this will work with a minor upgrade?

Sadly enough there will be no feature state changes with either of these releases (just some small bug fixes). The real reason we want to do this (besides releasing some bug fixes) is because at some point in the past we diverged to provide one “special” customer with a personalized software fix (done as a minor upgrade), we now want to bring them back into the main branch with everyone else. (We are tired of supporting multiple releases specific to a customer.)

[Stefan Krueger]

A minor update requires that the component rules are followed in both cases (feature-component tree not rearranged, not components removed in the new version, no component IDs changed, etc.). If this is true for both updates from both old version to the new version, then a minor update should work. If you are using InstallShield you can use its update validation to test this.