Decouple `icu_testdata` versioning from `icu`?

[robertbastian]

These should be versioned independently, as updating testdata should not bump the icu version.

Maybe something like 1.62 for ICU4X 1.x and ICU 62?

cc @dsipasseuth

[dsipasseuth]

as long as icu test data depends on anything from icu, i don't think it's possible.

but in theory, if it's only "data", it should not depends on icu. (data read should be string, bytes, anything available in standard lib but not an actual ICU defined structure)

i see this in the Cargo.toml

[dependencies]
icu_provider = { version = "1.0.0-beta1", path = "../core" }
icu_provider_adapters = { version = "1.0.0-beta1", path = "../adapters" }

we could in theory keep 1.0.0 test data set for all future 1.x.z ICU lib version.

now keeping libs in different version takes extra effort too. so it's also about what's make life simpler :)

[robertbastian]

icu_testdata would depend on a less specific version of icu[_*], like 1.

[sffc]

When components add new data structs, icu_testdata needs to be updated to have that minimum version. For example, if icu_datetime adds a new data struct in version 1.2, then icu_testdata needs to depend on version 1.2 and not anything lower than that. So I think it makes sense to keep icu_testdata major and minor versions parallel with the main component version.

However, when there is a new data update without any structure changes, I think it's totally reasonable for icu_testdata to have a new patch version.

If we wanted to, we could even leverage prerelease tags to link icu_testdata versions to CLDR versions. For example, 1.1.0 could mean "1.1 struct versions with latest data", and 1.1.0-cldr62 could mean "1.1 struct versions with CLDR 62 data".

[dsipasseuth]

Is it intended to have icu_datetime structure in icu_testdata and not in some other module like icu_datetime_test ?

[sffc]

It comes in via the baked provider.

[robertbastian]

Does cargo recognise that 1.1.0-cldr62 is later than 1.1.0-cldr61? Otherwise we could use the third fragment (1.1.62), assuming we're not going to change any data struct layouts in minor releases.

[sffc]

I was thinking we save the patch version for "latest stable"; when there is a new latest stable, we bump the patch version. The -cldr61 and -cldr62 is what you can use to opt in to a specific CLDR version. Note that we would likely want them to actually be more like -cldr61-alpha1 since CLDR has sub-releases that are important.

[dsipasseuth]

versioning are increment right ?

i.e : -cldr62 contains / include / is compatible with -cldr61-alpha1

[dsipasseuth]

I think the name of the crate is missleading.

testdata hints at something that just contains data. when it's actually much more.

Should we call it icu_test_framework ? icu_test_helpers ?

And by this naming, the versioning should follow the versionning of the icu to keep it simple.

the cldr version might be a mutually exclusive feaure ?

[sffc]

testdata hints at something that just contains data. when it's actually much more.

It has test data in several different formats, and it has convenience functions to enable vertical fallback, but that's basically it. It's not "much more".

[robertbastian]

We seem to be releasing frequently enough to not require special releases for CLDR bumps. We also now have SourceData::latest_tested, so icu_datagen is coupled to CLDR versioning the same way testdata is.