You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's possible to install dev versions (which often have the same MSI version as a release build) on the same machine. The result is that multiple MSIs are installed under the same name and the add/remove programs dialog only presents one of these for uninstall. Upgrades can also fail.
To fix this we're going to version dev builds as 0.1.0 (a version lower than the earliest MSI release version). Dev builds will install over whatever is already installed on the system so the user will get the version they're attempting to install when installing a dev version. However, GA released builds have later version numbers so they will always install over dev versions. GA versions will also upgrade linearly (same behavior as today)
Changes:
Make default Product Name something like Azure Developer CLI (dev) which is overridden during release build
Change upgrade logic to always upgrade if version is 0.1.0 (default if no version is specified)
Changes to build system:
On release build:
Specify Product Name
Specify Product Version
On non-release build:
Do not specify anything (this is the same as a dev build)
This will make it so daily/PR versions install over whatever is installed, but any GA releases can install over a non-GA versions, and GA versions will continue to upgrade linearly.
Installing a daily/PR version will fix the majority of cases where there are multiple versions of the MSI installed. All will upgrade to the dev version being installed.
The text was updated successfully, but these errors were encountered:
danieljurek
changed the title
[MSI] Dev/Release
[MSI] Dev/Release Upgrade Scenarios
Oct 3, 2023
* Allow dev builds to upgrade all versions
Resolves#2815
* EngSys changes to support release/dev MSI builds
* Ensure using parameters.Condition
* ##vso (thanks, copilot)
* Test: contrive a version update
* Use checked in version.txt
* Use version.txt
* Revert "Use version.txt"
This reverts commit 1da0c1f.
* Revert "Use checked in version.txt"
This reverts commit 64bc097.
* Revert "Test: contrive a version update"
This reverts commit b9092d0.
* Use version.txt from main
---------
Co-authored-by: Daniel Jurek <djurek@microsoft.com>
It's possible to install dev versions (which often have the same MSI version as a release build) on the same machine. The result is that multiple MSIs are installed under the same name and the add/remove programs dialog only presents one of these for uninstall. Upgrades can also fail.
To fix this we're going to version dev builds as
0.1.0
(a version lower than the earliest MSI release version). Dev builds will install over whatever is already installed on the system so the user will get the version they're attempting to install when installing a dev version. However, GA released builds have later version numbers so they will always install over dev versions. GA versions will also upgrade linearly (same behavior as today)Changes:
Azure Developer CLI (dev)
which is overridden during release build0.1.0
(default if no version is specified)Changes to build system:
This will make it so daily/PR versions install over whatever is installed, but any GA releases can install over a non-GA versions, and GA versions will continue to upgrade linearly.
Installing a daily/PR version will fix the majority of cases where there are multiple versions of the MSI installed. All will upgrade to the dev version being installed.
The text was updated successfully, but these errors were encountered: