Tracking issue for release 6

[sirhcel]

Bumping our MSRV is overdue. A fair amount of issues is waiting for it to get integrated. Let's sort what brings semver breaking changes and what requires a higher MSRV just for getting integrated. The milestone https://github.com/serialport/serialport-rs/milestone/1 does not make this distinction yet.

So let's get this planned at all and have a place for the discussions. Let's get started at all and update this issue as we go. Your Feedback and contributions are welcome.

Ideas:

• Switch from different platform-specific implementations of the TTYPort trait to a single struct (with platform specific implementations)
• Provive platform-specific functionality via extension traits
  • Like controlling RS-485 port settings on Linux (Add posibility to enable rs485 functionality for port under Linux #226)
• Allow splitting a serialport instance into a io::Read and io::Write half to conveniently allow reading and writing from different threads without synchronization overhead

PRs to integrate bringing semver breaking changes:

• Added support for 1.5 stop bits when reading current port settings #195
• Add Mark and Space variants to Parity enum #189

PRs requiring a higher MSRV for integration:

• Upgrade nix to v0.30 #263

Issues and PRs requiring some discussion and weighing:

• Localized implementation for Display for configuration parameter types? #317

[YgorSouza]

For breaking changes, there is also #189.

[sirhcel]

For breaking changes, there is also #189.

Absolutely. Thank you!

[ColinFinck]

It probably doesn't need to be said, but please consider upgrading all dependencies to their very latest versions once you raise the MSRV. Let me know if this needs an extra issue or PR.
The current Cargo.toml is full of pinned crate versions, making it very hard to use serialport-rs with other up-to-date dependencies (e.g. I'm also running into #307).

My current side goal is to update all windows-sys dependencies of my project to at least 0.69.0 in order to always use raw-dylib for Windows DLL imports. The current reality is that some are >=0.69.0 while others remain at <0.69.0 and sometimes fail when using non-MSVC toolchains. serialport-rs is one of them, with windows-sys currently pinned to 0.52.x.

It's sad that an MSRV increase is not universally accepted as a semver-breaking change. However, please reconsider whether serialport-rs should be the lone warrior correcting this mistake. For example, if core-foundation wasn't pinned to 0.10.0, people on old Rust versions could still pin it to 0.10.0 in their projects while everyone else could use 0.10.1.

[sirhcel]

That is a good point and I already started that at the playground for 5.0. The MSRV is at 1.75 there and all pinning of sub-dependencies is already gone.

My current side goal is to update all windows-sys dependencies of my project to at least 0.69.0 in order to always use raw-dylib for Windows DLL imports. The current reality is that some are >=0.69.0 while others remain at <0.69.0 and sometimes fail when using non-MSVC toolchains. serialport-rs is one of them, with windows-sys currently pinned to 0.52.x.

Are you sure with that version number? Looking at https://crates.io/crates/windows-sys/versions shows me 0.61.2 at the latest released version. I bumped windows-sys in the plaground to this version and it builds afters some minor modifications.

It's sad that an MSRV increase is not universally accepted as a semver-breaking change. However, please reconsider whether serialport-rs should be the lone warrior correcting this mistake. For example, if core-foundation wasn't pinned to 0.10.0, people on old Rust versions could still pin it to 0.10.0 in their projects while everyone else could use 0.10.1.

This is my biggest annoyance with Cargo's legacy dependency resolution. Things will get better as recent versions of Cargo started to take MSRV into account for dependency resolution but we have to wait one more Yocto LTS for
bumping our MSRV for using this feature for serialport as well.

[ColinFinck]

@sirhcel: Thank you for your quick reply!

Are you sure with that version number? Looking at https://crates.io/crates/windows-sys/versions shows me 0.61.2 at the latest released version. I bumped windows-sys in the plaground to this version and it builds afters some minor modifications.

I'm sorry, I was looking at the version tags in the https://github.com/microsoft/windows-rs repo and didn't realize that these version numbers weren't synchronized with each sub-crate... 🙈
microsoft/windows-rs#3741 states that "windows-rs Release 69" contains windows-sys 0.61.0, windows-link 0.2.0, etc.. 🙈

[sirhcel]

As we are notoriously low on hands, I wrote a proposal for the Rust Embedded Working Group's GSoC application.

[BartMassey]

I've edited the proposal linked above slightly, clarifying things and expanding the scope a bit. (I think this was too small for GSoC as-is — contributors tend to be quite capable and will work a minimum of 90 hours for a "small" proposal.) Folks here should take a look and see what I've done; I won't merge it until you are all OK with it.

[BjornTheProgrammer]

Is there anything that you need help with on this issue? Currently getting compatibility issues with core-foundation. I would be happy to submit some PRs.

[sirhcel]

What issues are you seeing with the core-foundation dependency @BjornTheProgrammer? I tried to build with 1.59.0 and are getting an MSRV-related error for proc-macro2 but not from the core-foundation crate.

Receiving more and more issues caused by our well aged MSRV I'm starting to think about splitting the agenda:

1. Just bumping MSRV, dependencies and landing the low-hanging PRs to get a release 5.0 with MSRV 1.75 out soon-ish
2. To start the bigger refactoring directly afterwards and shipping it with the next major release 6.0

I take no pride in low major releases so getting a more modern MSRV soon-ish seems to outweigh likely shipping two major releases in a short period of time.