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

Release 0.9.0 #632

Closed
10 tasks done
asomers opened this issue Jun 28, 2017 · 14 comments
Closed
10 tasks done

Release 0.9.0 #632

asomers opened this issue Jun 28, 2017 · 14 comments
Assignees

Comments

@asomers
Copy link
Member

asomers commented Jun 28, 2017

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.

@asomers asomers self-assigned this Jun 28, 2017
@Susurrus
Copy link
Contributor

#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 libc release for this as I'd like to get #527 merged we have a slew of other PRs that are pretty close. Specifically I'd like to nominate #566 and #629 which are pretty close and nice wins for nix. There are several others, but I don't think any are necessary fixes.

@asomers
Copy link
Member Author

asomers commented Jul 4, 2017

As long as we're committed to bumping libc anyway, then I'd like to finish PR #630 as well.

@Susurrus
Copy link
Contributor

Susurrus commented Jul 4, 2017

So the current list of PRs/issues I/we want addressed for 0.9 is:

This doesn't include a general fix to ptrace, but I haven't dug into that yet and I hadn't filed an issue.

@Susurrus
Copy link
Contributor

Susurrus commented Jul 7, 2017

Well libc 0.2.25 was just released, so we're good with dependencies on that end. We should make sure we don't merge anything that has required changes to libc since 0.2.25.

@asomers
Copy link
Member Author

asomers commented Jul 8, 2017

I would like to add issue #659 to the list. That kind of bug can take a long time to track down.

@Susurrus
Copy link
Contributor

Susurrus commented Jul 9, 2017

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 cargo-release. This reduces several of the steps into 1, and basically we only need to modify the CHANGELOG and README for releases.

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 libc version in a release branch and then migrate any desired PRs to that branch leaving any new ones to stay on master. This means that master is always "good" for merging new PRs since the libc version is still git.

@Susurrus
Copy link
Contributor

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).

@Susurrus
Copy link
Contributor

#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.

@Susurrus
Copy link
Contributor

I just added #681 and #686 to the list as they both fix runtime and compilation bugs. I think we're stalled on #566 so I'd suggest we punt on it. The other 3 are getting close to merging.

@Susurrus
Copy link
Contributor

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

@asomers
Copy link
Member Author

asomers commented Jul 21, 2017

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.

@Susurrus
Copy link
Contributor

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

@asomers
Copy link
Member Author

asomers commented Jul 24, 2017

Fixed by PR #705

@asomers asomers closed this as completed Jul 24, 2017
@Susurrus
Copy link
Contributor

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!

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

2 participants