icu_compactdecimal 1.3 and 1.4 do not build with latest fixed_decimal

[sffc]

fixed_decimal 0.5.6 changed CompactDecimal::exponent to return u8 instead of i16

https://docs.rs/fixed_decimal/0.5.5/fixed_decimal/struct.CompactDecimal.html

https://docs.rs/fixed_decimal/0.5.6/fixed_decimal/struct.CompactDecimal.html

I think this is a positive change, but it breaks icu_compactdecimal versions 1.3 and 1.4.

I think I prefer fixing this by releasing icu_compactdecimal 1.3.x and 1.4.x with a <= 0.5.5 version bound on fixed_decimal.

[sffc]

Ok? @Manishearth

[sffc]

I guess I could also release icu_compactdecimal 1.3.x and 1.4.x with a code change to use the new u8 functions.

[Manishearth]

Yes, I would do that instead, but really it feels like this means we should yank-and-break fixed_decimal

[sffc]

I want to turn the fewest cranks possible, and the fewest cranks is releasing icu_compactdecimal@1.3 and icu_compactdecimal@1.4 with a small patch that fixes the issue.

Yanking fixed_decimal due to the breakage is much more invasive:

• We release fixed_decimal@0.6.0
• All icu_* crates at 1.5 that have a dep on fixed_decimal need to be patch-released to use the new fixed_decimal
• Then we yank fixed_decimal@0.5.6
• icu_compactdecimal@1.5.0 assumes the u8 functions, so we'd have to yank icu_compactdecimal@1.5.0, too
• And then hope that we thought of everything

[Manishearth]

Ah, this is 1.4 being broken.

Yeah, okay, let's release <= revisions.

[Manishearth]

We may also need to yank older icu_compactdecimal? This is the kind of bound that may confuse cargo's resolver; i.e. cargo update may choose to update fixed_decimal but not icu_compactdecimal, which will be broken.

[sffc]

The issue is only observable when a client depends on ~1.3 or ~1.4 (as is the case in Unicode Conformance where we saw this).

[sffc]

Options:

1. Yank and break and turn cranks on 1.5 crates
2. Patch icu_compactdecimal 1.3/1.4 with <= dep
3. Patch icu_compactdecimal 1.3/1.4 with code change

I think I lean toward option 3 because the code change is small and it's less likely to confuse the resolver. I'm not sure what @Manishearth prefers because #5200 (comment) expressed a different sentiment than #5200 (comment)

[sffc]

With options 2 and 3, I don't propose yanking anything.

[Manishearth]

I prefer option 3, ideally if it can be done in a way such that patched icu_compactdecimal still works with unpatched fixed_decimal. I'm fine with being a bit loose about this since it's experimental.

because #5200 (comment) expressed a different sentiment than #5200 (comment)

I was never not in favor of the other two options, I just expressed a stronger preference for doing a breaking change if we broke ourselves, but given that it's past crates and given that it's a lot of cranks to turn, I'm fine not doing that.

The <= is acceptable but annoying for resolvers, (3) has the benefit of not breaking resolvers either, and makes everything guaranteed to be fixed by a cargo update.

[sffc]

Done: https://crates.io/crates/icu_compactdecimal/0.2.4

Turns out I only needed to release 0.2.4 because both 1.3 and 1.4 depend on 0.2.x. (In 1.5 it was moved to icu_experimental)

[sffc]

@Manishearth to review my pushes to https://github.com/unicode-org/icu4x/tree/release/1.4 and then close this issue.

[Manishearth]

Pushes lgtm

[robertbastian]

Technically 0.5.6 was a breaking change. The impact to icu_compactdecimal has been mitigated, but we might have broken clients. We cannot actually do a major bump, because FixedDecimal is part of the icu API through FixedDecimalFormatter::format, as well as through icu_capi. So I think we might want to revert the change.