Support version upgrade for MSI packages #1764
Conversation
|
|
||
| <MajorUpgrade | ||
| AllowDowngrades="no" DowngradeErrorMessage="A later version of ADOT Collectot is already installed. Setup will now exit" | ||
| AllowSameVersionUpgrades="yes" |
There was a problem hiding this comment.
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.
'''
There was a problem hiding this comment.
Can you please provide a bit more elaboration on the testing that was done manually. Preferably with a list of steps and desired outcomes. What was the problem exactly? Was the problem replicated first? What was the desired outcome? Was the desired outcome reached after this change was made?
|
|
||
| <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.
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.
I also think this doc could be relevant here.
There was a problem hiding this comment.
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 AllowSameVersionUpgrades="yes" to make sure customers can upgrade the collector even-though all the release versions are tagged at 0.0.1.
There was a problem hiding this comment.
@vasireddy99 looping you in for the comment you left above
There was a problem hiding this comment.
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 bump-version-create-release-note script could be updated. I created an issue here to track this requirement.
Description:
Previously installing a new version of ADOT collector, did not automatically uninstall the older version.
This PR adds support version upgrade for MSI build packages.
Testing: Tested it locally in a windows build system
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.