Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upcoming semver bump, to 1.0 #272

Closed
sunfishcode opened this issue Aug 10, 2022 · 11 comments
Closed

Upcoming semver bump, to 1.0 #272

sunfishcode opened this issue Aug 10, 2022 · 11 comments

Comments

@sunfishcode
Copy link
Member

sunfishcode commented Aug 10, 2022

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 #192, so I'm tentatively planning to have this next release be version 1.0.

@ChrisDenton
Copy link

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.

@sunfishcode
Copy link
Member Author

Ah, thanks for pointing that out. So all those other traits are already stable, which means we're probably good without any further changes.

@sunfishcode
Copy link
Member Author

The last remaining item here is #273. That's currently waiting for async-rs/async-std#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.

@bstrie
Copy link

bstrie commented Sep 2, 2022

It would be nice to have a release that contains the fix for #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?

@sunfishcode
Copy link
Member Author

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 async-rs/async-std#1036.

@sunfishcode
Copy link
Member Author

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.

@EdorianDark
Copy link

Considering that the last commit in async-rs main is from July and the lack of recent activity in async-rs/async-std#1036, does it really make sense to wait?

@sunfishcode
Copy link
Member Author

@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!

@sunfishcode
Copy link
Member Author

io-lifetimes 1.0 and rustix 0.36 are out; #281 updates cap-std.

@sunfishcode
Copy link
Member Author

1.0 is now released!

@cgwalters
Copy link
Contributor

Congratulations and nice work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants