Use prerelease tags for experimental crates

[robertbastian]

Currently our experimental crates are versioned fairly arbitrarily. For example, the 1.4 equivalent versions are:

• icu_compactdecimal: 0.2.3
• icu_displaynames: 0.11.2
• icu_relativetime: 0.1.4
• icu_transliterate: 0.1.2
• icu_unicodeset_parse: 0.1.2

I propose that from 1.5 we use prelease tags: 1.5.0-experimental or something. This is because these crates are fairly tightly coupled to the main version through data crates and cross dependencies, and it's confusing to users to have so many different versions. It also makes it clearer which GitHub release corresponds to which crate version.

We could even version them as 1.5.0, however adding -experimental will show them as unstable releases on docs.rs, in a way that 0.x actually doesn't. Nope, then we cannot make breaking changes in 1.6.0

[robertbastian]

I think a behaviour change here is that every ICU4X minor release will be a breaking release, as Cargo will not use 1.6.0-experimental if you ask for 1.5.0-experimental. Currently we do only bump minor versions if an experimental crate doesn't change across a release, but I'm not sure how important this is.

[robertbastian]

I would want to adopt this policy for all crates that will be versioned with the main version upon stabilization: components/, ffi/, and provider/. utils/ stay independent.

[Manishearth]

Discussed in small call:

• @Manishearth: I think prerelease tags are annoying (for everyone) but this is fine. They're not that annoying. I think consistency is better.
• @zbraniecki: Is using the prerelease tag a violation of semver?
• Unfortunately yes (see manishtest-alphaversions crate)
  • 1.0.0-experimental will not update to 1.1.0-experimental (yay)
  • 1.1.0-experimental will update to 1.1.0 (meh, won't happen for us)
  • 1.0.0-experimental will update to 1.1.0 (bad!!!)
• @Manishearth this means the moment we graduate an experimental crate, all old users will be immediately upgraded, in a breaking way. We can't do this.
• @Manishearth Another possibility is we use a well defined scheme, icu4x 1.5 == icu_experimental 0.1.5-experimental
• I believe cargo will refuse to update 0.1.5-experimental to 0.1.6-experimental, based on the test above.
• @robertbastian won't work for existing crates.
• @Manishearth we can for new crates, but i don't like this too much
• Maybe useful for future experimental crates post 2.0?
• @robertbastian - still pretty complicated, doesn't gain us that much

Conclusion: let's not do this for now (@Manishearth @robertbastian @zbraniecki)

cc @sffc in case he wants to chime in

[Manishearth]

It occurs to me that given that Cargo's docs explicitly say that you shouldn't bet on protection from breaking changes:

Beware that pre-release versions can be unstable, and as such care should be
taken when using them. Some projects may choose to publish breaking changes
between pre-release versions. It is recommended to not use pre-release
dependencies in a library if your library is not also a pre-release. Care
should also be taken when updating your Cargo.lock, and be prepared if a
pre-release update causes issues.

we still could do this and be following the norms set by Cargo. It's still going to potentially be annoying for our users.