Proposal from ICU for spec change policy
Activity
Mark Davis February 19, 2025 at 4:48 AM
Moved non-Accepted tickets to v48
Mark Davis February 18, 2025 at 11:46 PM
Setting back to Design, to resolved Shane’s questions.
Shane Carr February 6, 2025 at 2:26 PM
I don’t understand point 2. A lot of the time CLDR adds spec that doesn’t break ICU, but is an addition, and such test should definitely be tech preview.
About point 3, we should be more clear what constitutes an implementation. You say “(in at least draft status)”; that sounds like a requirement, so we should make it more explicit, not just an aside. And I think ICU4X should be listed; I don’t see why it is important that it is implemented in a “synchronized” release. I don’t know if ICU4X will ever have releases “synchronized” with CLDR since part of the value proposition of ICU4X is that it can read from different CLDR versions.
Mark Davis February 5, 2025 at 10:48 PM
I think once they are on a more closely linked schedule, we should.
Rich Gillam February 5, 2025 at 6:38 PM
Shouldn’t the proposed text mention ICU4X?
ICU runs into problems when we introduce a spec feature that affects their APIs. We discussed this in the ICU meeting, and are proposing the following in the
I think the basic change to our process would be to verify as of spec-beta which changes would qualify, and mark them as Tech Preview.
We (including ICU/ICU4X) might rework the wording of the principle as we start to apply it and find edge cases.
NOTE: the actual wording in the ICU meeting was “New spec features that (a) affect existing ICU APIs and (b) have neither been implemented by ICU nor ICU4X (in at least draft status) will be in Tech Preview in the CLDR spec.” I tried to make it clearer, but may not have preserved exactly what people wanted, so the above text needs review.