Update some obvious crate deps

[Firstyear]

This updates num_derive and bitfield. Next I want to update picky-asn but that will likely need a seperate PR.

[Firstyear]

For future, you can use "cargo outdated" to help with finding deps like this that need updates :)

[Superhepper]

Thank you for the PR.

You are indeed correct that the crate suffers from some outdated depedencies. Though that is probably due to the fact that we have a MSRV (Minimum Supported Rust Version) and when you update some dependencies it no longer work with older rust versions.

[Firstyear]

Ahhh that would explain it. I'm sorry I didn't notice the MSRV.

Even with that we should be able to update most of these I think :)

[ionut-arm]

Though that is probably due to the fact that we have a MSRV (Minimum Supported Rust Version) and when you update some dependencies it no longer work with older rust versions.

Which begs the question - what Rust version should we tie MSRV to? We're currently updating Parsec to 1.66 after a review of what the Linux distros we build for package, maybe we can do the same here.

[Firstyear]

I think I'm biased on this topic, since I'm the maintainer of rust for OpenSUSE and SUSE, and we follow upstream release cadence so we don't have an issue with MSRV being more aggressive.

Generally the rust community is very fast moving wrt to rust toolchain upgrades, but you will hit slower moving targets especially with fedora/centos/debian in this regard.

I would say you should consider the MSRV being tied to your release support policy. If you released say "today" and the release is supported for 6 months, then you set the MSRV to 1.70 or something around a similar time as "now". Then when you release in the future you bump the MSRV to what's out then.

But of course, this may affect different downstream consumers more or less. There isn't a perfect answer here.

As well, you only need to support an MSRV for an older toolchain if something on that distro is actually also shipping this library too - else it's just speculation.

Hope these thoughts give you some ideas. :)

[Superhepper]

For me it is not an issue regarding if we should update our MSRV but rather an issue regarding how this should be communicated. Because it have happened that crates have updated their MSRV and only bumped the minor or patch version of the crate and then Cargo happily just automatically uses the later versions of the crates and things breaks. So for me a MSRV update requires a "Major Version" bump. In order to avoid the risk of breaking something for some one else.

Ideally we would take the "main" branch as it is now bump the MSRV to suitable version and make 8.0.0 release. Though I release it may contain so many updates that it would be hard to adapt existing code to it.

[Firstyear]

I think a major version bump on MSRV change is fair :)

[ionut-arm]

So, it seems there isn't yet a full consensus on what the strategy should be for semver vs MSRV, but the tentative recommendation is to allow minor version releases to increase MSRV (but not patch releases).

I agree about the main branch release, though. I think v8 is due.

[Firstyear]

So, it seems there isn't yet a full consensus on what the strategy should be for semver vs MSRV, but the tentative recommendation is to allow minor version releases to increase MSRV (but not patch releases).

I agree about the main branch release, though. I think v8 is due.

I would be okay with this :)

[wiktor-k]

I'm very much OK with this change 👍 We can merge it as soon as the MSRV PR goes through.

[Firstyear]

Sounds good, I'll wait for the MSRV change then I'll rebase and update this PR.

[tgonzalezorlandoarm]

MSRV update PR: #445

[Superhepper]

@Firstyear You should try ton rebase this PR on the HEAD of main and see if it is possible to merge it.

[Firstyear]

Yep, I was thinking to just close this pr and start fresh :)