[release/9.0.1xx] Avoid workload gc failure due to 4-part version in ReleaseVersion used to find a max #46989
+41
−4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #46946
Context
Workload garbage collection fails after a 4-part workload set (like 9.0.100.2) has been installed because we try to find the latest version, and to do a proper version comparison, we attempt to cast the version into a ReleaseVersion. ReleaseVersions can only have up to three parts, so the four-part version fails.
Many linux users stick with the 100 banded SDK for a full year, only upgrading when the next 100 band is out. As a result, this bug will plague linux users for months to come unless it is backported to 9.0.1xx.
Customer impact
Workload garbage collection fails and logs an error. Things that should have been removed are not removed.
Details
Backport a change to compare the version numbers first then the prerelease part separately. This works because Version, unlike ReleaseVersion, supports four-part versions. Version cannot be used as a direct replacement for ReleaseVersion, however, because it does not support prerelease version parts. This hybrid solution was the cleanest solution short of adding support for one or the other in Version or ReleaseVersion directly.
Testing
These changes were previously merged to release/9.0.2xx, and they performed well there. Vendors discovered this only in 9.0.1xx. (It should technically exist in 8.0.4xx as well, but there was only one workload set with a four-part version ever produced for 8.0.4xx, and it's minimally used and not the latest version.)
Risk
Minimal: it has worked in 9.0.2xx for months with no known issues. It's a scoped fix.