Repository navigation
Prevent old version of PowerShell MSI from installing over newer versions #5834
Description
Activity
Travis Plunk (@TravisEz13) Should be as easy as (taken from official WiX documentation here)
<MajorUpgrade DowngradeErrorMessage="A later version of $(var.ProductName) is already installed. Setup will now exit.">Reacted by Travis PlunkTravis Plunk (@TravisEz13) I just built a couple of test MSIs and when trying to install a version that is older by either a digit in the minor or patch version, one already gets the following out of the box:
Unless we want to customise the message as per my above comment, I think we can close this one. WDYT?sounds good.
Do we want to enable preventing downgrades to preview releases?
I personally do not see the need/value of that, therefore it's up to you.
We get this for preview versions automatically if we add the feature in master branch. I see no problems - we can install previews side-by-side from zip distributives in any time.
The problem is the version is the same between previews and the final version. So downgrades from the final to preview is allowed. We would have to do something like adding a 4th place to the version which we increment at release.
I believe we could increment 1th, 2nd or/and 3rd places at releases and use 4th place for daily preview builds. But the 4th (revision) is only in Version type, SemVer hasn't a revision place. It seems we need a map of the types.
Maybe we better use GitVersion?
I think the tool can help to resolve many version problems, e.g #5846 by alpha/beta channels /cc Steve Lee (@SteveL-MSFT)I think we would update the 4th only for the milestone preview builds, but otherwise it shoulds correct.
Implementation of 4th will require a lot of work.
The use of 4th looks too difficult for the modern servicing model we use.
I reread GitVersion docs and believe we could do the following way:- Turn on auto increment PATCH per commit in 6.0.0 master branch.
- At the release time manually create release branch with 6.1.0 version and switch to 6.1.x version in master branch with again auto increment PATCH per commit.
Or we could make odd versions as development versions:
- Switch to 6.1.x version and turn on auto increment PATCH per commit.
- At the release time manually create release branch with 6.2.0 version and switch to 6.3.x version in master branch with auto increment PATCH per commit.
It seems such model resolve all problems with upgrades and simplified release process.
Update: I think we should consider to switch from GitHubFlow to GitFlow
Using the third digit during previews is not needed. I don't believe there is a good reason to capture the information we are putting in the 4th digit in the SemVer. I'd rather just live with the downgrade issue or manually change the 3rd digit before release.
Or, make the odd versions the development versions.
2 remaining items
Ah, do you suggest not to increase 4th every prerelease?
I wouldn't. As you suggest, it would add hidden information that would be confusing. The main goal is to prevent people from downgrading from the release build to a pre-release build, without a warning.
From Christoph Bergmeister (@bergmeister) link above:
Increment the Version value in your Product element to be higher than any previous versions that you have shipped. Windows Installer only uses the first 3 parts of the version in upgrade scenarios, so make sure to increment your version such that one of the first 3 parts is higher than any previously shipped version. For example, if your version 1 uses Version value 1.0.1.0, then version 2 should have a Version value of 1.0.2.0 or higher (1.0.1.1 will not work here).
We skip that MSI don't support 4th part.
Solution for 4th requires a custom action and looks complicate https://stackoverflow.com/questions/16642518/can-we-upgrade-1-0-0-0-to-1-0-0-1-while-changing-product-code
I think we need to use the experience of other teams:
https://github.com/stuartleeks/dotnet-cli/blob/master/Documentation/cli-installation-scenarios.md#channels
https://support.google.com/chromebook/answer/1086915If we use channels, we do not need to worry about their conflicts - ordinary users will only use the product channel, testers and developers will use either the beta channel or the development channel. Those who want to combine versions of different channels can use AppImages.
As for the version numbering, we need to go back to my comment above.
It seems you are suggesting we can close this.
I don't think it's worth the effort to prevent downgrades to prerelease versions.
Should we fix this for release versions? (Disable downgrade for release versions)
Also what do you think about using the channels and branches - release, beta, develop?
I don't know if we should disable downgrade for release versions. If someone installs 6.1 and we made a mistake introducing a regression, they may want to roll back to 6.0 until we fix it in a newer version.
I believe we discussed having multiple branches for stable vs experimental, but decided against it unless there's a real need for it.
they may want to roll back to 6.0 until we fix it in a newer version
They'll to have first uninstall new version and only then install previous. This protects against silent downgrade.
but decided against it unless there's a real need for it
Was it internal discussion? In recent days I'm looking at the CoreFX model - it seems more flexible and consume less resources after we have the release and we need the servicing.
Per Christoph Bergmeister (@bergmeister) Downgrade for release versions is already blocked. #5834 (comment)
Yes, I skipped that this is enabled by default.
I checked and WiX does what the article says by default. I think the property mentioned only changes the error.
Reacted by IlyaYes, the property is only a customisation of the error message.
Instructions are here
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370840(v=vs.85).aspx
Update: per Christoph Bergmeister (@bergmeister) , the msi already prevents downgrades.
We should also consider if we need to block downgrade to prerelease versions.