You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're getting pretty close to being able to compile uefi-rs on the stable channel. 🎉
I believe Rust 1.68 will have everything we need; that release is expected on March 9, 2023. I propose the following steps once the stable release occurs:
If we've accumulated significant changes since the previous release, go ahead and do another release as the final release that supports a 3-month old nightly.
Drop our current nightly MSRV policy and switch to a new policy based on stable releases (more on this below).
Merge in the two remaining PRs needed for the library to work on stable.
Do another release. (This will be the first release that works on stable, but it will still be a 0.x release of uefi-rs since (IMO) we're not ready yet to promise there won't be breaking API changes.)
As to what the new MSRV policy should be, there is not yet much consensus in the ecosystem for us to use as guidance. See rust-lang/libs-team#72 for one interesting discussion containing a lot of viewpoints. Obviously if we support stable 1.68 then our initial policy will have to be just be N-0 since earlier stable releases don't work. We could then expand that policy to be a little more conservative like N-1 (support current and previous stable releases). I imagine at most we might go for N-2, I don't think we have much reason to go earlier than that for now.
The text was updated successfully, but these errors were encountered:
Do another release. (This will be the first release that works on stable, but it will still be a 0.x release of uefi-rs since (IMO) we're not ready yet to promise there won't be breaking API changes.
Yes, I'm fine with that. No need for v1.0.0
I think N-2 is fine, as the Rust ecosystem is mature enough that we do not rely on bleeding edge functionality that much.
If we've accumulated significant changes since the previous release, go ahead and do another release as the final release that supports a 3-month old nightly.
We don't have that many accumulated changes, so I don't think we need to bother with another release prior to switching to stable. I'll do one right after we merge the changes to allow stable, which should be very soon since 1.68 is scheduled for tomorrow.
We're getting pretty close to being able to compile uefi-rs on the stable channel. 🎉
I believe Rust 1.68 will have everything we need; that release is expected on March 9, 2023. I propose the following steps once the stable release occurs:
0.x
release of uefi-rs since (IMO) we're not ready yet to promise there won't be breaking API changes.)As to what the new MSRV policy should be, there is not yet much consensus in the ecosystem for us to use as guidance. See rust-lang/libs-team#72 for one interesting discussion containing a lot of viewpoints. Obviously if we support stable 1.68 then our initial policy will have to be just be
N-0
since earlier stable releases don't work. We could then expand that policy to be a little more conservative likeN-1
(support current and previous stable releases). I imagine at most we might go forN-2
, I don't think we have much reason to go earlier than that for now.The text was updated successfully, but these errors were encountered: