#612 Burn upgrades should support a version range
It's unnecessary to change the UpgradeCode even for side-by-side releases in Windows Installer because the Upgrade table supports min and max versions. Burn should mimic this behavior to support MSIs that do not change the UpgradeCode between major releases that do not support major upgrades (i.e., they are instead side-by-side releases). This supports scenarios like SxS MSIs that need to register the latest install path (like an SDK). Consider WinSDK that writes its latest install path to VS to locate headers and libs.
- Install VS (any version).
- Install WinSDK 6.0
- Install WinSDK 7.0
- Repair (reinstall) WinSDK 6.0
VS now has the path for WinSDK 6.0 which is not the latest. Instead, WinSDK 6.0 (and future versions) could have used a custom action to determine the latest product installed via MsiEnumRelatedProducts since the UpgradeCode would never change (under this assumption). There's no way WinSDK 6.0 could have known about 7.0 or any future versions of the SDK. Without inventing a new registration scheme to track versions, WinSDK can use an MSI API to find the latest version using fixed data (the UpgradeCode).
To support these sorts of scenarios, Burn should support a version range for its upgrade feature.
This is the design of upgrades in Bundle.