cap-std
cap-std copied to clipboard
bytecodealliance
Upcoming semver bump, to 1.0
cap-std and cap-async-std will need a semver bump in order to pick up the fix for #270, which is needed in order to compile with changes to nightly Rust.
~~I'm also considering making the same change as #271 for FileExt, MetadataExt, DirBuilderExt, PermissionExt, OpenOptionsExt, to future-proof against std sealing those traits in the future.~~ [edit: see comments below]
To minimize the number of semver bumps, I'm also planning to coordinate these changes with another change, when I/O lifetimes makes it to stable Rust (expected Aug. 11), and I update io-lifetimes to use it when available.
That's the main change contemplated in https://github.com/bytecodealliance/cap-std/issues/192, so I'm tentatively planning to have this next release be version 1.0.
I'm also considering making the same change as #271 for
FileExt,MetadataExt,DirBuilderExt,PermissionExt,OpenOptionsExt, to future-proof against std sealing those traits in the future.
Note that if a trait is already stable it's very unlikely to be sealed later precisely so as to avoid breakages similar to the one with FileTypeExt. On the other hand, nightly only traits have no stability guarantees and can break at any time.
Ah, thanks for pointing that out. So all those other traits are already stable, which means we're probably good without any further changes.
The last remaining item here is #273. That's currently waiting for https://github.com/async-rs/async-std/pull/1036 in order to support cap-async-std. Another option would be to do a 1.0 release for all the crates except cap-async-std for now.
It would be nice to have a release that contains the fix for https://github.com/bytecodealliance/cap-std/pull/271 , so that users are not stuck on old versions of the Rust toolchain. If you think that a true 1.0.0 release is blocked on other crates, would you be interested in doing a 1.0.0-pre prerelease for the time being?
Sure. I've now published a 1.0.0-rc1 of cap-std et al.
Except for cap-async-std, as that's waiting for https://github.com/async-rs/async-std/pull/1036.
I've also now released a v0.26.0-patch1, which is 0.25 plus #271 and a few other fixes, without the io-lifetimes updates, so it includes a cap-async-std release.
Considering that the last commit in async-rs main is from July and the lack of recent activity in https://github.com/async-rs/async-std/pull/1036, does it really make sense to wait?
@EdorianDark Yes, I think the best option at this time is to do a 1.0 release without cap-async-std for now. That'll take a few steps, as it wants a 1.0 release of io-lifetimes and a 0.36 release of rustix. Assuming those go smoothly, cap-std 1.0 is next!
io-lifetimes 1.0 and rustix 0.36 are out; https://github.com/bytecodealliance/cap-std/pull/281 updates cap-std.
