Prepare for 0.4.13 release

[KodrAus]

cc @fggarcia @Byron

This includes #434, which was a bug when a combination of kv_unstable and std features was enabled in log.

[KodrAus]

I'm just checking this against smol locally before pushing it out. Thanks for the reports everyone!

[KodrAus]

Ok, so smol's issue is actually a different one. We've changed a few things on the unstable key-value API that affects tide, so I'll go follow up with them before publishing anything.

[Byron]

Thanks! Thus far everything still builds with v0.4.11.
Something I am a bit anxious about is to use -AlphaN in versions as these may contain breaking changes while cargo update will happily update to more recent versions. Since log now depends on value-bag that uses this versioning scheme, I fear breakage can happen at any time from now on.

[KodrAus]

That's a fair concern 👍 The value-bag crate is fully encapsulated in log's API, and the plan is to release a 1.0 of it as soon as possible once we've got this release stabilized.

[KodrAus]

This release is waiting on: yoshuawuyts/kv-log-macro#8

[Byron]

That's a fair concern 👍 The value-bag crate is fully encapsulated in log's API…

The way I see it, any breaking change to value-bag (assuming it keeps the version scheme) must trigger a respective release of the log crate in lock-step. Thus for a moment after a new value-bag release is made, new log installations using the log crate will fail until the respective compatible log crate version is published.

I fail to see a way to avoid that with the current versioning scheme, unfortunately, and given the omni-presence of log with 34.5 million downloads it's likely to cause some raised eyebrows no matter how quickly the crates are published. Also I wonder if cargo should do something about it as I believe it's quite common to try to have RC's or Alphas on the path towards a new major version.

Anyway, excuse my ramblings 😁.

[KodrAus]

It sounds like I've misunderstood how -AlphaN versions are treated. I expected them to behave like = dependencies, where you'll only get exactly that version.

I had been planning to fully stabilize value-bag before stabilizing the key-value API, it sounds like that's going to be a hard requirement now.

[Byron]

After having checked the comparison rules of semver it appears it's absolutely by design, and no issue in cargo. To me this means that stable software should never refer to an alpha version of a crate unless one pins the version like so crate = "=0.1.0-alpha1" in the cargo manifest. This is something you could do to keep using the alpha crate, but it's certainly worth testing this out before relying on my word given the importance the log crate for the ecosystem 😅.

[Keruspe]

Not sure what happened while publishing 0.4.13, but it doesn't seem to be the same as master? 0.4.13 still depends on cfg-if 0.1 when master switched to 1.0 a while back

[KodrAus]

@Keruspe You're right, it is different than what's on master, the release notes for 0.4.13 have a note on what's up with that release:

This is the same as 0.4.11, except with a kv_unstable_std feature added to aid migrating current dependents to 0.4.14 (which was originally going to be 0.4.13 until it was decided to create a patch from 0.4.11 to minimize disruption).

That release is based off the 0.4.11-patch branch. So what was going to be 0.4.13 is now going to be 0.4.14, which I'm planning on releasing next week. #437 is tracking that. It might be a little confusing but that release is going to be fairly short lived, then the dependency improvements we made will be out on crates.io!