Will rust 1.59.0 be a barrier to using the newer create?

[sweet-de-way]

Over time, many third-party libraries are updated to take advantage of new features and improvements in Rust. If your project depends on these libraries and they no longer support Rust 1.59.0, using an older version of the compiler may become a problem.

For example, windows-sys 0.59.0 requires libc 0.2.164 to build on some platforms.

#228

[sirhcel]

Yes, using MSRV 1.59.0 is already a barrier and this is getting more of a challenge as rust releases progress. The reason we are using this "prehistoric" release as our MSRV is the latest long-term support release of Yocto (for building embedded Linux distributions) provided this Rust release.

A new long-term support release of Yocto is out and I wanted to tackle this long overdue bump of the MSRV together with a bigger refactoring of the interface (like #34, #94 ...). But it looks like this is too much asked and not gonna happen soon.

I consider bumping our MSRV as a semver breaking change. The seralport crate stumbled more than one time over dependencies bumping their MSRV with a minor release and I'd like to spare users this not so pleasant experience. That's why I'm starting to get inclined to do split this up in two major releases:

• Release 5.0 for bumping the MSRV to 1.75.0 (which is the one supported by the current long-term support release of Yocto)
• Releaso 6.0 for transitioning to a platform-specific representation of SerialPort

So a switch to windows-sys could land with each of them.

[unlimitedsola]

• Release 5.0 for bumping the MSRV to 1.75.0 (which is the one supported by the current long-term support release of Yocto)

Hi, I'm also seeing a lot of PRs are currently blocked by this MSRV requirement, so I wonder when could this happen? Should we start branching out with a newer MSRV so that we can start getting PRs merged and have a foundation to work on?

[sirhcel]

Hi, I'm also seeing a lot of PRs are currently blocked by this MSRV requirement, so I wonder when could this happen? Should we start branching out with a newer MSRV so that we can start getting PRs merged and have a foundation to work on?

Which PRs are you referring to here? For sure, the list of PRs and also tagging them. As of now both, semver breaking and MSRV breaking changes are tagged as 5.0.0. We could and likely should split this up between semver and MSRV breaking changes.

[unlimitedsola]

Which PRs are you referring to here?

I'm referring to PRs that are tagged with 5.0.0. There are currently 8 open PRs that are tagged with 5.0.0 and over half of them require resolving conflicts due to they are pulled against main, and the work for migrating to window-sys will likely be one too, due to the amount of cleanup we need after we bumped MSRV if we stay 1.59.0.

We could and likely should split this up between semver and MSRV breaking changes.

The question is how should we proceed? Should we start merging MSRV breaking changes into main? or should we at some point bump the MSRV to 1.75.0 (as you've said the Yocto project is the main deciding factor anyways) on main first so that pending PRs can have a working foundation without also adjusting the MSRV themself and causing conflicts with each other? and when could this happen? Are there issues that we have to resolve before bumping MSRV?

I'm willing to help with splitting PRs into API breaking and MSRV breaking parts, with goals to have them merged, however. But it is also worrying to see that simple MSRV breaking PRs like #76 have waited for 2 years with no sign they will be merged.