Repository navigation
Prevent old version of PowerShell MSI from installing over newer versions #5834
Description
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.
Activity
bergmeister commentedon Jan 9, 2018
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.">bergmeister commentedon Jan 11, 2018
Travis 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?
TravisEz13 commentedon Jan 11, 2018
sounds good.
TravisEz13 commentedon Jan 11, 2018
Do we want to enable preventing downgrades to preview releases?
bergmeister commentedon Jan 11, 2018
I personally do not see the need/value of that, therefore it's up to you.
iSazonov commentedon Jan 12, 2018
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.
TravisEz13 commentedon Jan 12, 2018
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.
iSazonov commentedon Jan 13, 2018
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)
TravisEz13 commentedon Jan 15, 2018
I think we would update the 4th only for the milestone preview builds, but otherwise it shoulds correct.
iSazonov commentedon Jan 16, 2018
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:
Or we could make odd versions as development versions:
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
TravisEz13 commentedon Jan 17, 2018
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
iSazonov commentedon Jan 18, 2018
Ah, do you suggest not to increase 4th every prerelease?
TravisEz13 commentedon Jan 20, 2018
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.
iSazonov commentedon Jan 20, 2018
From Christoph Bergmeister (@bergmeister) link above:
We skip that MSI don't support 4th part.
iSazonov commentedon Jan 20, 2018
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
iSazonov commentedon Jan 20, 2018
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/1086915
If 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.
TravisEz13 commentedon Jan 22, 2018
It seems you are suggesting we can close this.
SteveL-MSFT commentedon Jan 24, 2018
I don't think it's worth the effort to prevent downgrades to prerelease versions.
iSazonov commentedon Jan 24, 2018
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?
SteveL-MSFT commentedon Jan 24, 2018
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.
iSazonov commentedon Jan 24, 2018
They'll to have first uninstall new version and only then install previous. This protects against silent downgrade.
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.
TravisEz13 commentedon Jan 24, 2018
Per Christoph Bergmeister (@bergmeister) Downgrade for release versions is already blocked. #5834 (comment)
iSazonov commentedon Jan 24, 2018
Yes, I skipped that this is enabled by default.
TravisEz13 commentedon Jan 26, 2018
I checked and WiX does what the article says by default. I think the property mentioned only changes the error.
bergmeister commentedon Jan 26, 2018
Yes, the property is only a customisation of the error message.