search

rust-pcap / pcap

Rust language pcap library
Apache License 2.0
620 stars 144 forks source link

Todo list for 0.8.0 #132

Closed Wojtek242 closed 3 years ago

Wojtek242 commented 4 years ago

So far, we have roughly done:

What would we like to aim for for the 0.8 version? IMO, this should be a bring-up-to-date version + fix some of the more pertinent issues - new features should be added only if they fix such issues. We've done the bring-up-to-date part already so what else would we like for 0.8?

I think one useful update for 0.8 would be to redo the support for different libpcap versions. Currently functions from newer versions are feature gated (each function having its own feature). This is not scalable, makes maintenance a pain, makes PRs more complex than they should be. To fix this we should first decide what the oldest libpcap version we want to support. In #118 we noted that libpcap 1.4.0 is still supported on CentOS 6. However, since that reaches EOL in December, I'd got with 1.5.3 which is what CentOS 7 supports. Then, we can decide how to handle features from 1.5+. On my fork I added a build-time libpcap version detection (https://github.com/Wojtek242/pcap/pull/3) with the option of manually choosing a version. It works well if you're compiling the code yourself, but probably has problems if you want to ship the code. Something we can discuss further in #118. I'm happy to own this particular issue.

Apart from that, I'd go through the issues and PRs and decide which ones need to be sorted out by 0.8 and which ones are not that important.

sekineh commented 4 years ago

Since we renamed tokio feature, it might be a nice timing to reconsider other feature names/mechanism.

sekineh commented 4 years ago

I created 0.8.0 milestone to collect issues that need to be included in 0.8.0.

We could add GitHub Actions job for publishing to crates.io. Example in python package

Wojtek242 commented 4 years ago

I've gone through all the issues and added labels and the 0.8 milestone for issues I think should be resolved for 0.8 (basically anything that's a bug or questions, but not enhancement).

We should also go through the PRs to see if they're still relevant. If they're relevant we should ask the submitters if they would like to update them or close them.

Wojtek242 commented 4 years ago

I will have a stab at #118 this weekend which should help resolve some of the issues and PRs related to features.

Wojtek242 commented 4 years ago

I've submitted two more PRs to resolve some outstanding bugs (#141 and #143) for the 0.8 milestone. Once #110 is resolved, then that's all the bugs we actually marked for the 0.8.0 release : ). After that it would probably be good to go through the outstanding PRs and merge/adapt those that are beneficial and complete the release with #142.

Wojtek242 commented 3 years ago

At this point, we have addressed all the outstanding issues that were bugs or in some way severely limited the usability of the library. I have also gone through all the outstanding PRs and either closed them or manually merged them in after some clean up if they were useful (effectively the only PRs I merged this way were docstrings and BPF compile). Once #149 is reviewed and merged, I think it's time to release 0.8.0.

Anything else we should do? If nothing comes up in the next two weeks, I'll just proceed with the release.

Wojtek242 commented 3 years ago

Closing as I have now published v0.8.0: https://crates.io/crates/pcap