Release uefi-0.14.0 and uefi-services-0.11.0

[nicholasbishop]

As noted in https://github.com/rust-osdev/uefi-rs/issues/339, the current released versions don't compile with current nightly. We should do new releases to fix this.

There haven't been any commits to uefi-macros since the last release, so only uefi and uefi-services need new releases.

I think I have the necessary permissions now, so I'll give this a try.

[nicholasbishop]

This is done now. Some notes:

I used cargo-release (v0.19.1) to see if that made things easier, with mixed results.

First I ran the commands in the default dry-run mode:

cargo release --no-verify --tag-prefix=uefi- --package=uefi 0.14.0
cargo release --no-verify --package=uefi-services 0.11.0

• --no-verify is needed to skip the build test, which otherwise fails because there's no way to specify the --target currently.
• For uefi, I added --tag-prefix=uefi- so that it would create a uefi-v0.14.0 tag. (Not needed for uefi-services, since that one is in a subdirectory and so automatically gets a uefi-services- prefix.

Then I ran the first command in execute mode to actually release:

cargo release --no-verify --tag-prefix=uefi- --package=uefi 0.14.0 --execute

This successfully released uefi-0.14.0 to crates.io. It also updated the local repo's Cargo.toml files to point at the new release. But, it failed when pushing that change to github because the master branch is protected from direct pushes. Tags were pushed, however.

So I made a PR manually containing that commit, at which point I noticed that the version deps were updated to include a ^ prefix. I believe that's unnecessary, as far as I know the behavior of package = "^x.y.z" is identical to package = "x.y.z". To avoid unwanted churn I manually changed it to remove the caret and pushed to master.

Then I did the same thing with uefi-services:

cargo release --no-verify --package=uefi-services 0.11.0 --execute

Again, it was successfully released but I had to do a manual PR. I also noticed that the commit message just said "(cargo-release) version 0.11.0", rather than "(cargo-release) uefi-services version 0.11.0", which I thought was a little unclear so I edited that manually.

Finally, I manually tested the release by copying the template to a new directory, updating its deps to point at the latest release, and checking that it builds.

Some things to improve on:

• Is there a way to pass --target to cargo-release? Might be worth filing a bug for it if not.
• Could I have released both packages in one command? Might have required setting the tag prefix for uefi- in a config file, not sure of the details.
• Is there a way to make cargo-release not insert ^ into the version? Minor annoyance.
• Is there a way to make cargo-release include the package name in the commit? Again, minor annoyance.
• Is there a better way to handle the commit that updates the deps since the master branch is protected?

[GabrielMajeri]

@nicholasbishop thank you for trying out and documenting the cargo-publish approach! Have you opened any issues in their repo to implement the additional features we'd require? If not, I'd look into it, since the cargo-publish developers might find these options useful for other projects as well.

Is there a better way to handle the commit that updates the deps since the master branch is protected?

Hmm, the problem is, I don't know/think GitHub offers a way to decide which commits can be made directly to master and which can't. We've agreed a long time ago to make the main branch protected to avoid accidental changes that didn't pass review or which break tests, but haven't come up with a better way to get minor changes merged in.

[nicholasbishop]

I put up a PR for the --target issue: https://github.com/crate-ci/cargo-release/pull/396, haven't looked into the other issues yet.

Hmm, the problem is, I don't know/think GitHub offers a way to decide which commits can be made directly to master and which can't. We've agreed a long time ago to make the main branch protected to avoid accidental changes that didn't pass review or which break tests, but haven't come up with a better way to get minor changes merged in.

I haven't fully thought this idea through, but we could probably move the release process into a github workflow. Maybe have a manual workflow (no automatic triggers) that gets the crates.io token from a repository secret. And/or maybe use an environment for deployment, if I'm understanding the docs correctly that would allow releases to be reviewed similar to a PR.

Having the master branch protected is certainly nice, I like knowing that I can't accidentally push to the wrong branch, so wouldn't want to change that.