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.

[fpagliughi]

I'll pile on here, too. Using Yocto, we've learned to put Cargo.lock files into our repo for all of our internal Rust crates to ensure that MSRV updates to our dependencies don't break our build.

I assume that everyone using Rust on Yocto has learned this lesson?

But that has also freed me to bump the MSRV on my own open-source hw/embedded Rust crates without worrying about breaking my own builds and everyone else's. I love that cargo added a Minimum RSV, but I wish they would also add a Maximum RSV to resolve the latest version of dependencies that don't break the build.

I think the latest Yocto Rust version is a good target for MSRV in a crate like this. MSRV 1.75 would be really helpful right now.

[paolobarbolini]

As time moves on more and more dependencies bump MSRV. Even tokio has been requiring >1.59 for 1.5 years. Is there any chance that with the new MSRV aware resolver we could relax the MSRV requirement?

As @fpagliughi said in Rust it's very important to lock your dependencies by committing Cargo.lock to your repositories. This not only helps with this but it's good in general for reproducibility and controlling when things are updated.

I also find the Rust versions in Yocto to be highly outdated and unusable in many cases. It's comparable to trying to get the current Rust ecosystem to build on Debian Bookworm (Rust v1.63), except that for them at least a good part of the community still tries to care for it.
Anyways, maybe this crate could be like tokio: multiple minor versions are supported. Only important fixes are backported (I'd also make it on request) and at least this way development can move forward and not be blocked by a 3 years old OS release (although I get that most of the community is still stuck on it 🙄).