chore: deps update to minor versions and fix did-key upstream dep

[zeeshanlakhani]

Let our deps float on patch versions and fix did-key upstream dep issues.

[pinkforest]

Fixes #49

[cdata]

@zeeshanlakhani thanks for this change. Can you share the rationale for restricting the version ranges this much?

At a glance, it seems unnecessary to me; as a library, we should be liberal with version ranges so that applications can restrict versions as it suits their use case.

[zeeshanlakhani]

@zeeshanlakhani thanks for this change. Can you share the rationale for restricting the version ranges this much?

At a glance, it seems unnecessary to me; as a library, we should be liberal with version ranges so that applications can restrict versions as it suits their use case.

Oh, I don't think we're being too restrictive. We're essentially letting patch versions float, but you don't want feature/major versions to float because they may contain breaking changes, and sometimes minor versions can cause issues as well. With this at least, if dependabot gets a new minor, we can run it through CI.

[cdata]

I think I agree @zeeshanlakhani but in semantic versioning, 1.0 floats on patch, not minor. ^1 floats on minor. Am I missing something?

[zeeshanlakhani]

@cdata my bad, I was texting over mobile at the doctor's office. Yes, this lets patches float, where as some libs, e.g. tokio/tracing/etc, even hardline on the patch.

[pinkforest]

FWIW - Rust ecosystem has whole lot of SemVer exemption footguns to be aware of -
This is why it is common to restrict at major.minor as a lot of breaking changes are exempted to minor bumps
Luckily anyhow's maintainer is very particular about SemVer - often they are not when e.g. deps are exposed via public API's

Raised #51 to perhaps clarify policy.

[cdata]

This looks fine. Thanks for the insights re: semver in cargo.

As a general rule, we should stay liberal with regards to version ranges. If there are specific dependencies that are known to be "bad" semver citizens, we can deal with those on a case-by-case basis. Similarly, if there are dependencies that are highly sensitive (like crypto primitives), let's consider those candidates for more cautious version range strategies. In all special cases, we should document the rationale with comments.

Thanks for making this update!