Unicode version upgrades as not semver breaking

[hsivonen]

It appears that this crates treats Unicode version updates as semver breaks. E.g. unicode-normalization and unicode-bidi don't treat Unicode version updates as semver breaks.

Would you be willing to make Unicode version updates not semver-breaking going forward?

I'm considering making the unicode-rs back end option (see servo/rust-url#939 (comment) and servo/rust-url#939 (comment)) for the idna crate depend on this crate, and I'm going to make Unicode updates not be semver breaking for the idna crate.

If going forward unicode-joining-type could make Unicode version updates not semver breaks, I could make idna_adapter depend on unicode-joining-type directly (like unicode-normalization and unicode-bidi). (Otherwise, I need to do a hack to put unicode-joining-type behind idna_mapping and lose a bit of build parallelism; see the above-linked comments for what idna_adapter and idna_mapping are contemplated to be.)

[wezm]

Would you be willing to make Unicode version updates not semver-breaking going forward?

Yes that sounds fine. This and our other Unicode crates probably should be published as 1.0 and then updates could only bump the minor version number.

[wezm]

Actually it looks like unicode-normalization and unicode-bidi are only bumping the patch version... is that right? I know the API stays the same but it feels like importing a whole new Unicode dataset warrants more than just a bump of the patch version since it can change behaviour.

[hsivonen]

Thanks!

unicode-normalization and unicode-bidi need to bump the patch version only, since bumping the middle component is semver-incompatible when the major component is zero. Logically the crates should be past 1.0, but like encoding_rs, doing a 1.0 release would cause a semver break without a real API break, so it would be unnecessary churn.

If this crate is going to do 1.0, that's a semver break, so I guess for now I should prepare for unicode-joining-type doing at least one non-API-breaking semver break.

[wezm]

@hsivonen I've applied the Unicode 16 update and am preparing next steps. I was wondering if you had any thoughts on how to best minimise semver breaking changes in the face of updates like this one, which added variants to the JoiningGroup (and also removed one)—all driven by the Unicode data.

Marking the enums with non_exhaustive would handle the case of additions but removing a variant would still be a breaking change I think.