On Wed, Nov 30, 2022 at 9:59 AM Jeff Davis <pg...@j-davis.com> wrote: > Here's what I found for the 'ar' locale (firstminor/lastminor are the > icu library versions, firstcollversion/lastcollversion are their > respective collation versions for the given locale): > > firstminor | lastminor | firstcollversion | lastcollversion > ------------+-----------+------------------+----------------- > 60.1 | 60.3 | 153.80.32 | 153.80.32.1 > 64.1 | 64.2 | 153.96.35 | 153.97.35.8 > 68.1 | 68.2 | 153.14.38 | 153.14.38.8 > (3 rows)
Right, this fits with what I said earlier: the third component is CLDR major, fourth component is CLDR minor except from ICU 61 on the CLDR minor is << 3'd (X.X.38.8 means CLDR 38.1). I wrote something about that particular CLDR upgrade that happened in ICU 68 back here, with a link to the CLDR change list: https://www.postgresql.org/message-id/ca+hukgjxg6abkc9rj7r1byvltvvkthqv+rzo6bkvwyespcp...@mail.gmail.com TL;DR that particular CLDR change didn't actually affect collations, it affected other locale stuff we don't care about (timezones etc). We probably have to assume that any CLDR change *might* affect us, though, unless we can find a written policy somewhere that says CLDR minor changes never change sort order. But I wouldn't want to get into 2nd guessing their ucol_getVersion() format, and if they knew that minor changes didn't affect sort order they presumably wouldn't have included it in the recipe, so I think we simply have to treat it as opaque and assume that ucol_getVersion() change means what it says on the tin: sort order might have changed. > I suppose the next step is to test with actual data and find > differences? Easier to read the published CLDR deltas, but I'm not sure it'd tell us much about what *could* happen in future releases...