Skip to content
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

[release/9.0.1xx] Avoid workload gc failure due to 4-part version in ReleaseVersion used to find a max #46989

Merged
merged 3 commits into from
Mar 11, 2025

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Feb 20, 2025

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.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Workloads untriaged Request triage from a team member labels Feb 20, 2025
@nagilson
Copy link
Member

This Helix leg timed out: https://helix.dot.net/api/jobs/1ae6516e-09ad-4453-a9a8-9467bd656717/details?api-version=2019-06-17 so I've restarted it.

@github-actions github-actions bot force-pushed the backport/pr-45263-to-release/9.0.1xx branch from 78faa5f to ed9379d Compare March 3, 2025 20:49
@Forgind Forgind added Servicing-consider and removed untriaged Request triage from a team member labels Mar 3, 2025
@Forgind Forgind added this to the 9.0.1xx milestone Mar 3, 2025
@dsplaisted
Copy link
Member

@Forgind Can you link the 9.0.2xx PR that this is backporting from?

@Forgind
Copy link
Member

Forgind commented Mar 3, 2025

@Forgind Can you link the 9.0.2xx PR that this is backporting from?

#45263

@rbhanda rbhanda modified the milestones: 9.0.1xx, 9.0.4 Mar 4, 2025
@edvilme edvilme merged commit b36f977 into release/9.0.1xx Mar 11, 2025
32 of 36 checks passed
@edvilme edvilme deleted the backport/pr-45263-to-release/9.0.1xx branch March 11, 2025 16:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants