Bump v0.1.0 release for temporal_rs and temporal_capi

[nekevss]

Drafting a pull request for the v0.1 release.

Merging is going to be dependent on two questions / tasks:

• What should the version for timezone_provider and zoneinfo_rs be?
• Is the release post reviewed and ready?

Regarding the question around versioning, I've left them still in the 0.0.x path until the APIs can be a bit more stabilized. But I'm open to adding them to a 0.1.0 version. My main concern is if we do make a breaking change to timezone_provider in the future (like stablizing the ZeroCompiledTzdbProvider) , then we may have to adjust the versions then for timezone_provider to be a 0.2.0 and temporal_rs to be a 0.1.1. I'd prefer to do a delayed 0.1 for those crates, but that is not an incredibly strong position.

[Manishearth]

Regarding the question around versioning, I've left them still in the 0.0.x path until the APIs can be a bit more stabilized. But I'm open to adding them to a 0.1.0 version. My main concern is if we do make a breaking change to timezone_provider in the future (like stablizing the ZeroCompiledTzdbProvider) , then we may have to adjust the versions then for timezone_provider to be a 0.2.0 and temporal_rs to be a 0.1.1. I'd prefer to do a delayed 0.1 for those crates, but that is not an incredibly strong position.

I think 0.0.x is in general a bad versioning scheme to stick to because it means every update is breaking. We should only be using that for crates that are highly experimental.

That is not the case for timezone_provider. It has a reasonable amount of polish. It's not perfect, but we're not evaluating for 1.0.0, we're evaluating for 0.1.0. 0.1.0 is what most crates start at. I think it should very clearly be 0.1.0, and it is totally fine if its versioning diverges from temporal_rs; since it's a dependency. We can even use range deps to give people flexibility when needed.

I see very little utility to timezone_provider and temporal_rs having linked versioning in the 0.x.0 stream.

[Manishearth]

For zoneinfo, I think it's fine to consider that to still be half-done and experimental until we have a full end-to-end impl, so 0.0.x is fine, because it won't have clients. But I think we should just not be using 0.0.x for anything with clients; it is painful for clients to deal with because every patch is Cargo-breaking.

[nekevss]

That is not the case for timezone_provider. It has a reasonable amount of polish. It's not perfect, but we're not evaluating for 1.0.0, we're evaluating for 0.1.0. 0.1.0 is what most crates start at

Fair enough. I rolled over the version on timezone_provider. I do want to keep zoneinfo_rs lower though, at least until the provider using its data is implemented and tested.

[jasonwilliams]

Yep, agree with @Manishearth on the versioning rstional

[Manishearth]

Yeah, my general take on 0.0.x is "don't use this", which is true for zoneinfo_rs. timezone_provider is production ready even if the API isn't the final polished one.