Release 0.10.0

[asomers]

It's been more than three months since a release. Let's do another. The most important things to include IMHO are PR #790 because it fixes a build failure with newer versions of libc, and issue #788 because it's a backwards incompatible change. We want to release #788 as soon as possible to minimize the number of affected users.

Add milestone 0.10.0 markers to any other issues or PRs that you think must be included.

[Susurrus]

I'd suggest we also modify our release procedure a little here. We have 3 things tracking this release, this issue, the milestone, and then tags for issues. The tags and the milestone are redundant, since things targetting a specific milestone have visual indicators. And the milestone itself can contain a description, much like you provided one here.

I'd also propose that whatever we figure out about this procedure gets updated in RELEASE_PROCEDURE.md.

[Susurrus]

@asomers I'd like to make the 0.10 release happen soon here as it updates up to bitflags 1.0, which is ended up being a big breaking change throughout the ecosystem, so I'd like us to be in sync with that. Any progress on #788? Or do you know when you might be able to get to it?

[asomers]

Yeah, I've got #788 working. But before I submit a PR I want to make sure that everything is hunky-dory in the dependent crates too. Hopefully I can find some time during the holidays to finish it.

[Susurrus]

@asomers I'm deferring to you as the release manager what the next steps are. I think we're ready for a release. I'd also suggest we use cargo-release instead of the process outlined in RELEASE_PROCEDURE.md, as it's quick and should minimize manual errors. As part of that, I'd suggest we update that document as well so it can be relied on (I'd also like to link to it from our README in some way that is supported by GitHub and crates.io ideally).

[asomers]

Completed by PR #844 and PR #845 . I didn't use cargo-release, because that doesn't take care of updating our CHANGELOG and README files. It isn't clear how to do those in combination with cargo-release.

[Susurrus]

Then I'd suggest we file a bug with cargo-release as it'd be nice for us to have a simpler release process.

I'd also be curious if we could cut down on the steps we do that involve bors, as that can be a pain with Travis' Mac builds.

[asomers]

Instead of cutting down on bors, how about we cut down on Travis instead? Is there a way to tell Travis not to bother building a PR if the only changed files are pure documentation, like the README?

[posborne]

Instead of cutting down on bors, how about we cut down on Travis instead? Is there a way to tell Travis not to bother building a PR if the only changed files are pure documentation, like the README?

I doubt there is anything builtin to do this. You would have to look at the diff and terminate early if you thought that change was not worth testing. Here's one example I was able to find (on react) that does this: https://github.com/facebook/react/pull/2000/files

[asomers]

It's a little more manual, but it looks like we can tell Travis not to build something by putting [ci skip] in the commit message. https://docs.travis-ci.com/user/customizing-the-build/

[Susurrus]

There isn't yet, but Appveyor has it, so that's cool. See travis-ci/travis-ci#6301