-
Notifications
You must be signed in to change notification settings - Fork 676
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
Release 0.9.0 #632
Comments
#610 doesn't affect things really, it's mostly a test/CI issue, so it doesn't matter if it's in a release so much as it gets fixed in git. I'd actually suggest we wait until the next |
As long as we're committed to bumping libc anyway, then I'd like to finish PR #630 as well. |
So the current list of PRs/issues I/we want addressed for 0.9 is:
This doesn't include a general fix to |
Well |
I would like to add issue #659 to the list. That kind of bug can take a long time to track down. |
I'd also like to modify our release process for 0.9.0. The main thing is to reduce the number of steps by using I don't know if we want to do it for this release, as I don't want to change the process too much in one go, but I'd also like us to use branches for our releases so it's easy to create patch releases. So only fix the |
We should also deal with #306 at some point, but exposing it to all the appropriate platforms will take another libc release. Maybe instead we limit it to the platforms that libc supports now, even if it's a reduction in platforms (which is better than the current status of it just not compiling). |
#306 is fixed with #681, which was easy because the code was already broken so nobody has been using it for a while. We can add it back after the next libc release because rust-lang/libc#670 was already merged. |
@asomers in addition to #566 which is the only one we're blocking on now, there's two PRs addressing platform support. I hate to keep delaying this release, but I'd suggest we try to get #688 in as that's just to support compilation on that target (rustup really need to get support for OpenBSD!). And there's also #693 that would be good to improve our Android support. My suggestion is to get them in and defer on all other PRs until #566 lands + 24 hours. Then we release. Thoughts? |
I don't think it's worth holding up the release for #688. Since we won't be building it in CI, it's likely to break again soon. So OpenBSD users will probably have to pull in nix by specific known-good git revisions. Basically, I think that releases aren't very relevant for Tier 3 and lower. So I wouldn't hold up the release for it, though we can certainly merge it if it's ready in time. I feel mostly the same way about #693, even though it's Tier 2. |
@asomers Alright, I'm fine with that. We gotta cut a release at some point! So with the release process, what were you thinking about for that? I'm going to be leaving in a few hours and out of town all weekend, but I'm fine with you releasing whenever you want here. As part of that I'd also like to suggest we also post an Announcement on https://users.rust-lang.org that gives a summary of the changes. I think that should probably be added to the release process notes if you agree. |
Fixed by PR #705 |
Thanks, @asomers! And great job on the post to u.r-l.o. looks great and hopefully it'll recruit some new users and developers! |
I think it's time to make a new release. It should definitely include a fix for issue #610, and possibly any other PRs that are close to completion. But it should not include PR #630 , because that depends on an unreleased version of libc.
ioctl
moduleThe text was updated successfully, but these errors were encountered: