Minimal Rust suported version

[Stargateur]

From https://github.com/rust-pcap/pcap/pull/229#issuecomment-1100893055

I'm very opposite to such restriction, it way too much restrictive, in my opinion, if an user have upgrade problem requirement they need to use a FIXED version of rust crates. I think we must find a middle ground, this would lock this crates to 1.41 for 2 years. It's not viable for developing a crate in Rust where you want to use stable.

I'm open to have between 3 and 12 months before increase the mrsv and agree if we update the major for that (at the bar minimum update mrsv should update minor). Crates in Rust generally choice 6 months (tokio is 3 for example). I know nom try to follow ubuntu release (but there are every years where debian are 2 years so 12 months versus 24)

Specially, pcap is a library not an application.

TL;DR my opinion are:

• 3 months: Yes
• 6 months: Ok
• 12 months: meh
• 24 months: No
• 48 months: Hell no

If I understand correctly debian LTS is at least 60 months....

[Wojtek242]

I don't see a reason why this crate should update its msrv so frequently. It doesn't see enough activity for that. I will sometimes not even check on it for 3 months and it was at one point unmaintained for 2-3 years and yet it survived. I also adhere to the "if it ain't broke, don't fix it" philosophy. I actually don't like the breakneck speed of rust crate development and I don't like using rustup. I would strongly prefer to use a distro provided compiler hence sticking to Debian's versions.

We really don't need the hottest and newest rust features as seen by the fact that we've been locked to 1.40 for over a year now and until 0.8 the crate didn't even use Rust 2018. If something cannot be implemented due to the oldest supported version being too old then that feature has to wait or be implemented behind an optional feature, just like capture-stream.

I think an msrv newer than what Debian LTS supports can be considered for a particularly important/valuable code upgrade, not a minor feature development. At some point ignoring LTS in favour of just the main Debian support period of 36 months could be considered.

[Stargateur]

I don't see a reason why this crate should update its msrv so frequently. It doesn't see enough activity for that. I will sometimes not even check on it for 3 months and it was at one point unmaintained for 2-3 years and yet it survived. I also adhere to the "if it ain't broke, don't fix it" philosophy. I actually don't like the breakneck speed of rust crate development and I don't like using rustup. I would strongly prefer to use a distro provided compiler hence sticking to Debian's versions.

My point was not about have automatic msrv update, but talk about a range where if we need a feature of Rust we accept to upgrade the mrsv to this range. Also, limiting the mrsv limit the help you receive from contributor, it's limit the dev speed, it's limit a lot of thing actually. And again if people have problem with a pcap release they can lock their version. We limit ourself for nothing from my point of view. You may not use rustup but rustup is used by almost every Rust dev I know. Unless you convince me with a critical problem with using rustup I don't accept your argument here.

We really don't need the hottest and newest rust features as seen by the fact that we've been locked to 1.40 for over a year now and until 0.8 the crate didn't even use Rust 2018. If something cannot be implemented due to the oldest supported version being too old then that feature has to wait or be implemented behind an optional feature, just like capture-stream.

Having feature that require different mrsv could confuse pcap user and make dev complicated. I'm not sure it's wise.

I think an msrv newer than what Debian LTS supports can be considered for a particularly important/valuable code upgrade, not a minor feature development. At some point ignoring LTS in favour of just the main Debian support period of 36 months could be considered.

It's just way too long we talk about 3 years, honestly such requirement could drive me away of maintaining this crate. I'm a rolling release team, I agree to have a middle ground with people who like stable release but I can't accept more than 1 year. Again pcap is a library not a application. We don't have follow a distrib release cycle it's doesn't make sense. Our user doesn't install rust-pcap on a debian. If some people use rust-pcap on debian and want to use paquet manager I encourage them to create a .deb. But limit our mrsv according to debian release make no sense for me.

An application that use rust-pcap would follow your logic but we as lib that make no sense.

When I commit on a github repo I don't want to have a 3 years delay to what I dev for the future user of this lib... that not maintaining something it's barely keeping it alive without any hope for the future.

[Wojtek242]

it's limit the dev speed, it's limit a lot of thing actually

This crate doesn't have much dev speed in the first place. And it doesn't need it really - it's only a nice safe wrapper around a C library anyway. It doesn't need many new features to be perfectly honest. The features for which people use this crate are mostly in libpcap anyway. Furthermore, it's been working almost unchanged (apart from cleanup and some small new additions) since 2017.

Having feature that require different mrsv could confuse pcap user and make dev complicated. I'm not sure it's wise.

I don't understand this. Any rust version newer than 1.40 can compile this crate. This stability is promised by the rust devs. Users who wish to use nightly can still use/compile this crate. If they develop their own crate/code with newer they are welcome to do so and pcap will just work.

But limit our mrsv according to debian release make no sense for me.

Sticking to an msrv in line with Debian allows devs who use the distro provided rustc to compile this project. So it does matter.

You raise interesting points, but due to the scope and amount of dev activity around this crate really does not justify a newer msrv. And as I already mentioned, using newer rust features can be implemented, they just must be optional feature-gated. This crate was originally incredibly conservative with supported version (of libpcap back then) and I don't intend to move away from this without a good reason.

[Wojtek242]

Having feature that require different mrsv could confuse pcap user and make dev complicated. I'm not sure it's wise.

Ah, I misunderstood this point in the previous reply. I would actually argue that this is what features are useful for. Have the base library supported on a particular MSRV, but if you plan to use pcap with a newer rust compiler, you can enable some newer and cooler features that require a newer MSRV. Currently, capture-stream does not state what MSRV it needs other than it needs to compile tokio. This seems like a reasonable strategy to me. No features: specific MSRV, features: no MSRV, if it works with your compiler then great.