-
Notifications
You must be signed in to change notification settings - Fork 5k
Bump the minimum ICU version to 60 #112713
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
Conversation
As ICU approaches version 80, we need to consider what to do about our ICU version ranges. Our system currently supports a min version of 50 and a max of "min + 30", so 80. ICU60 is the version that shipped with Ubuntu 18.04, which is the distro that we base our libc version on. For Alpine, the version of ICU in the distro we base our libc on (3.17) ships with ICU 72. I recommend that we bump our min to ICU60, which will by our current rules bump our max to ICU90, which will give us more runway. I'd recommend holding off on merging this until dotnet#112671 is merged, as that PR changes our deps packages to better describe scenarios where we actually ship packages today.
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.
Copilot wasn't able to review any files in this pull request.
Files not reviewed (6)
- src/native/libs/System.Globalization.Native/config.h.in: Language not supported
- src/native/libs/System.Globalization.Native/configure.cmake: Language not supported
- src/native/libs/System.Globalization.Native/pal_collation.c: Language not supported
- src/native/libs/System.Globalization.Native/pal_icushim.c: Language not supported
- src/native/libs/System.Globalization.Native/pal_icushim_internal.h: Language not supported
- src/native/libs/System.Globalization.Native/pal_timeZoneInfo.c: Language not supported
Tagging subscribers to this area: @dotnet/area-system-globalization |
@jkoritzinsky did we check all Linux systems which .NET support are using ICU v60 and up? I am asking because we usually get some unexpected systems like Centos distros which runs with older versions of ICU. I don't have the full list to tell. @richlander may know more here? Did we consider changing only the max number instead? I am not opposing the change more than want to feel comfortable we'll not breaking any supported system. |
@tarekgh, looking at https://pkgs.org/search/?q=libicu, I see that for the min version of each distro that we or our partners support we have at least ICU60 available. RHEL8 is the only one with only ICU60, all other RHEL-based distros are further ahead. OpenSUSE and SUSE Enterprise Linux install ICU73 by default. The original version of Windows that shipped with ICU has the APIs from ICU60, so we should be good there too. |
I did quick research using copilot and I am getting the following list. Can we assume we are not supporting any of these systems?
|
Here is the Windows versions that support older ICU versions. I am not sure if we need to care about it. Windows servers use ICU versions 61+ though.
|
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.
LGTM, thank you!
All of these versions are either out of support or not supported by .NET.
The minimum version of Windows 10 that we support that supports ICU is 1809 RS5, which has at least ICU 60. We also support 1607 RS1, but that doesn't have ICU. We don't support RS2-4 any more for .NET 10 based on the matrix I shared above. |
Thanks for doing this. The approach looks sound. |
It feels like we need a peer doc to the OS-onboarding one which is a "stuff we do every release" doc. The ICU topic would go in that. Is that something we can start together? It can be super barren at first. Sven's work with our build container images would be a natural fit. Same with the "managed code" image I created. |
We could also pick a larger number than +30, e.g. looks like on Android we already use |
We try loading the ICU library starting from the max and decrement till we find the match. Increasing the max with a much bigger number can have some perf cost. CC @janvorli |
Right, it would likely add to the startup time which is not what we want. |
ah yeah, I forgot about that. we could still flip that around though, e.g. right now with latest ICU 76 we'd try 16 times vs. 14 times with the 90 ceiling. the benefit is that it'd not suddenly break, just get a bit slower over time. |
The point of going backwards was to ensure that we load the latest one if multiple ones are present on the system. Due to its versioning mechanism, it is possible to have multiple versions installed on the same distro IIRC. |
As ICU approaches version 80, we need to consider what to do about our ICU version ranges. Our system currently supports a min version of 50 and a max of "min + 30", so 80.
ICU60 is the version that shipped with Ubuntu 18.04, which is the distro that we base our libc version on. For Alpine, the version of ICU in the distro we base our libc on (3.17) ships with ICU 72.
I recommend that we bump our min to ICU60, which will by our current rules bump our max to ICU90, which will give us more runway.
I'd recommend holding off on merging this until #112671 is merged, as that PR changes our deps packages to better describe scenarios where we actually ship packages today.