chore: prepare [email protected], [email protected], [email protected], [email protected]

[jlizen]

📬 Issue #, if available:
n/a

✍️ Description of changes:
Preparing releases for new changes to various crates.

Breaking changes

I was considering #955 as a semver breaking change since it is changing the serialized output type of a field. It seems like it would mostly break tests since customers are not really serializing request structs in the wild, rather they are deserializing. But test breakage is still breakage.

And since that is a breaking change, lambda_http would be breaking by bumping its dependency.

Glad to revise this if other maintainers feel differently.

Not bumping patch versions on path dependencies

Meanwhile, I intentionally did not bump path dependency versions for non-breaking (patch version) changes. Since, all that really accomplishes is break somebody that for some odd reason wants to pin back to an older version and/or is using an older mirror of the crates.io index or something.

Anyway cargo resolution will use the newest version for any consumers that aren't pinning it. So, I don't see much benefit.

Generally you only see larger repos like tokio bumping patch versions of patch dependencies when they want to explicitly use a new API.

🔏 By submitting this pull request

• I confirm that I've ran cargo +nightly fmt.
• I confirm that I've ran cargo clippy --fix.
• I confirm that I've made a best effort attempt to update all relevant documentation.
• I confirm that my contribution is made under the terms of the Apache 2.0 license.

[bnusunny]

LGTM