-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support version upgrade for MSI packages #1764
Changes from 4 commits
79ac2c9
00add70
9a53dc0
6f17637
0502ef8
4204097
27acbb8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -20,6 +20,12 @@ SummaryCodepage='1252' | |
InstallScope="perMachine" | ||
Platform="x64" | ||
/> | ||
|
||
<MajorUpgrade | ||
AllowDowngrades="no" DowngradeErrorMessage="A later version of ADOT Collector is already installed. Setup will now exit" | ||
AllowSameVersionUpgrades="yes" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. After reading the docs for this field here, I am wondering if this is the correct solution. I do not think we should be in a situation where we need to perform upgrades for the same version. We also do not use the fourth version field. Would a viable solution, which also may be required anyways, be to ensure that this version field is upgraded before each collector release? I think a time when this COULD happen would be if the end user was building their own windows packages. This would cause the same version to be different. This should never be true for our official released assets MSIs though. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I also think this doc could be relevant here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, that is a good point. My initial thinking after reading the docs was on updating release version after each CD trigger. But it looks to be tricky as this needs to be passed as a env variable while running this file. We use the cached msi packages from successful CI run which are then used by our CD workflow. So one possible solution is to rebuild the MSI package during our CD workflow to make sure we have access to the version parameter. This approach needs a bit of refactor, so I temporary set There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @vasireddy99 looping you in for the comment you left above There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think updating the version should be a step in the release process before triggering the CD. It may have to be done manually or the |
||
/> | ||
|
||
<MediaTemplate EmbedCab="yes"/> | ||
|
||
<Feature Id="ProductFeature" Title="ADOT Collector" Level="1"> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have to set this to no. As we don't usually look after the fourth version field and may not be useful setting.
'''
This is useful when two product versions differ only in the fourth version field. MSI specifically ignores that field when comparing product versions, so two products that differ only in the fourth version field are the same product and need this attribute set to yes to be detected.
'''