-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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/6.0-staging] Fix Ordinal Ignore Case string compare #84386
[release/6.0-staging] Fix Ordinal Ignore Case string compare #84386
Conversation
Tagging subscribers to this area: @dotnet/area-system-globalization Issue DetailsBackport of #71022 to release/6.0-staging /cc @tarekgh Customer ImpactTestingRiskIMPORTANT: If this backport is for a servicing release, please verify that:
|
@tarekgh - The new |
This is approved by email. |
Requirements for merging:
|
The change here is in corelib which doesn't need OOB authoring. Additionally, the CI failures are not related to the change and are known issues. |
The change here is in corelib which doesn't need OOB authoring. additionally, the CI failures are not related to the change and are known issues. |
Backport of #71022 to release/6.0-staging
/cc @tarekgh
Customer Impact
A customer has reported a regression in .NET 6 where sorting with ordinal ignore case produces different results compared to .NET 5.0 and .NET Framework. The issue only arises when dealing with non-ASCII strings that contain characters with support casing. This can be challenging for the customer to troubleshoot and may manifest in various scenarios, such as deserialization across frameworks or user applications that rely on algorithms like binary trees or sorting.
Example of the broken behavior, when sorting
Ѱa
andѰB
,ѰB
will come beforeѰa
The fix for this issue was already included in .NET 7.0. While we previously tried to backport the fix through a pull request PR, it was recommended that we wait and observe if more users experience the same problem. However, as we have received reports and requests from users to bring the fix to .NET 6.0, we are currently considering this option. More information can be found at #84251.
Testing
Have done manual testing to ensure we are getting the right behavior. I have added more tests to ensure I catch this problem if it happens again in the future. The change has passed all regression tests.
Risk
The risk associated with this change is low, as it is specific to the problematic scenario and is intended to correct the behavior. I do not anticipate any negative impact or interference with other processes. Additionally, since we have already implemented this fix successfully in .NET 7.0, the risk level is further reduced, given that there were no adverse effects reported following the implementation.