Update bare-metal dependency

[hellow554]

Bare-metal has released its 1.0 version. Let's use it!

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @adamgreig (or someone else) soon.

Please see the contribution instructions for more information.

[hellow554]

Okay... I see.
I think it's time to release the 0.8 version I guess? :)

[adamgreig]

Thanks for the PR! You're right that this will need to go into cortex-m 0.8 due to being a breaking change, but I don't think there's any reason to do that soon - we don't have any other breaking changes queued up for cortex-m at the moment, and there's no new features granted by using bare-metal 1.0 or removing this impl except for breaking a bunch of the ecosystem that's still migrating to the newer InterruptNumber traits (especially since not all PACs have updated to the version of svd2rust that generates it).

Once we have a few more breaking changes or large new features queued up for cortex-m 0.8, we'll definitely include this PR in it, and possibly get rid of bare-metal all together (if we can figure out a better way to handle the Mutex).

[hydra]

See also #353 which includes a bump of bare-metal to the latest semver-compatible non-breaking change release which could potentially be included in 0.7.4?

[hydra]

Hi again, with regards to this PR being scheduled for 0.8 release, how do you guys plan/prepare for the next release? I note that you have master, staging and trying branches but master and staging are even and trying is old. It would perhaps be nice to have a pre-release / nightly branch that PR's like this can be merged into so that those on the bleeding edge can use, or those with CI systems that build against current and nightly can gain visibility of new features, breaking changes and deprecations.

[adamgreig]

The staging and trying branches are just for bors, they're generated automatically when someone asks bors to merge or try a PR. Otherwise we essentially have the master branch and sometimes old release branches (0.6.x etc).

This PR is nominally slated for 0.8, but we're not planning to release 0.8 any time soon -- we specifically want to leave plenty of time for the ecosystem to stop using the old bare_metal, which takes a lot of time to work through. If we end up wanting to release 0.8 sooner, this PR might even wait until after that, since all it does in effect is remove bare_metal::Nr.

Nevertheless you're right in general, it would be nice to have more managed branches for release management. We don't really have a wg-wide strategy at the moment beyond a fairly ad-hoc use of branches to manage patch releases to older minor versions.

[newAM]

RTIC is using bare-metal v1 for their upcoming 0.6 release (currently on 0.6.0-rc2). Might be a good idea to make this change around the same time to maintain compatibility for critical section tokens.

[adamgreig]

Master branch is already now for 0.8 development (since it has some breaking changes from 0.7), so let's get this merged too. Thanks again and sorry for the wait!

bors merge

[bors]

Merge conflict.

[adamgreig]

bors merge

[bors]

Build succeeded!

And happy new year! 🎉

• ci-linux (1.40.0)
• ci-linux (stable)
• clippy
• rustfmt