-
-
Notifications
You must be signed in to change notification settings - Fork 31.6k
Update ICU4C major version for NodeJS #46352
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Backwards-compatible changes that can be back-ported from Current to LTS release lines eventually are, meaning ICU will be updated if possible but it can take a few months. You can see it in the history: e.g. v14.x started out with ICU 66.1 and is now at 70.1. You mention ICU 73. See https://github.com/nodejs/Release#release-schedule - it'll arrive in v18.x sooner or later but almost certainly not in v16.x and v14.x because they're near their end of life. |
Hi Ben, Thanks for the response. We wanted to understand if it is safe to configure our internal NodeJS 14 and 16 imports to use ICU4C 72 using the approach mentioned here. Note that NodeJS 14 is consumed by multiple applications internally. How should we test that there is no regression if we configure Node 14/16 to use ICU4C 72 ? Are there any specific test suites we should run, in addition to unit tests? If possible, can you point us to the process used by NodeJS development community to update ICU4C major version on these NodeJS major versions? Thanks, |
https://github.com/nodejs/node/blob/main/doc/contributing/maintaining-icu.md#how-to-upgrade-icu is the process we follow. Even then stuff slips by, for example when we updated Node.js 14 to ICU 69 it took 18 months for #45784 to be raised. |
I'll close this as answered but I can convert it to a discussion if you have follow-up questions. |
Uh oh!
There was an error while loading. Please reload this page.
What is the problem this feature will solve?
Looking at the active NodeJS releases, I see that they are bundled with different ICU4C major versions:
Node 14 is on ICU 70: v14.21.2. Node 14 was originally launched with ICU 66.
Node 16 is on ICU 71: v16.19.0. Node 16 was originally launched with ICU 69.
Node 18 is on ICU 72: v18.13.0. Node 18 was originally launched with ICU 71.
I wanted to understand what is the process followed by NodeJS to update ICU4C major version.
Based on the documentation, it is possible to configure NodeJS with a different ICU4C major version than what it was originally bundled with. But is it safe (NodeJS versions specify a minimum ICU version, but is there a maximum)? What are the steps to validate that such an override is not introducing any regression?
ICU major releases include locale data updates (new CLDR releases). Some of these updates include critical updates for formatting correctly in some locales: (currency , number format, etc), e.g., CLDR-14708, CLDR-15992 and CLDR-15066. We also have an urgent number formatting update for en-ZA locale, which will be incorporated by CLDR in the upcoming release.
Typically a CLDR major release x is included in ICU4C major release x + 30, e.g., CLDR 42 was released with ICU 72.
We would like Node major versions 14, 16 and 18 to be updated with the latest ICU4C release when the patch for en-ZA is available in CLDR/ICU4C (either upcoming minor release for ICU4C 72 or upcoming major release ICU4C 73 (expected in April 2023)). Will this be possible?
If not, is there a guideline on whether it is safe to follow documentation to configure NodeJS with a higher ICU4C major version than what it was bundled with? Is there a maximum ICU4C major version for a NodeJS major version?
Thanks,
Abhijeet
What is the feature you are proposing to solve the problem?
Support for latest Internationalization (ICU4C/CLDR) data in all actively supported NodeJS releases (Node 14, Node 16 and Node 18).
What alternatives have you considered?
Based on the documentation, it seems possible to configure NodeJS with a different ICU4C major version than what it was bundled with. But is it safe (NodeJS versions specify a minimum ICU version, but is there a maximum)? What are the steps to validate that such an override is not introducing any regression?
The text was updated successfully, but these errors were encountered: