prepare release for `embassy-rp` & dependencies

[rursprung]

see the individual commit messages for further details.

what this PR does for the affected crates:

• it adds changelog entries for the new releases
• it adds release automation using cargo-release
• it fixes release/bump-dependency.sh (inadvertently created backup files, leading to lots of untracked files)

what this PR does not do:

• it does not run release/bump-dependency.sh for the crates (should only be done after the release of each crate)
• it does not enter a version number or release date in CHANGELOG.md (now taken care of by cargo-release)
• it does not prepare a new release for embassy-sync: while there were already new commits again there was just a release a few days ago so it's probably not yet needed?
• it does not add cargo-release setup for any other embassy crates. i'm floating this here as a test balloon

suggested flow of this PR for reviewers with commit access to the repo & release rights on crates.io:

1. review & merge the PR
2. install cargo-release (cargo binstall cargo-release)
3. run the following steps from latest main (after the merge) in a clean repo:

pushd embassy-futures
cargo release patch --execute
popd
# no need for this since it's just a patch: ./release/bump-dependency.sh embassy-futures 0.1.2
# if you do it anyway you should also do this: git commit -am 'update to `embassy-usb` v0.1.2'

pushd embassy-usb-driver
cargo release patch --execute
popd
# no need for this since it's just a patch: ./release/bump-dependency.sh embassy-usb-driver 0.1.1
# if you do it anyway you should also do this: git commit -am 'update to `embassy-usb-driver` v0.1.1'

pushd embassy-net-driver-channel
cargo release minor --execute # or possibly also patch if `embassy-sync` has no impact on the public API & cross-crate compatibility?
popd
./release/bump-dependency.sh embassy-net-driver-channel 0.4.0
git commit -am 'update to `embassy-net-driver-channel` v0.4.0'

# no commit for this in this PR since it has no changelog
pushd embassy-hal-internal
cargo release minor --execute
popd
./release/bump-dependency.sh embassy-hal-internal 0.3.0
git commit -am 'update to `embassy-hal-internal` v0.3.0'

pushd embassy-executor-macros
cargo release minor --execute
popd
./release/bump-dependency.sh embassy-executor-macros 0.7.0
git commit -am 'update to `embassy-executor-macros` v0.7.0'

pushd embassy-executor
cargo release minor --execute
popd
./release/bump-dependency.sh embassy-executor 0.8.0
git commit -am 'update to `embassy-executor` v0.8.0'

pushd embassy-time-driver
cargo release patch --execute
popd
# no need for this since it's just a patch: ./release/bump-dependency.sh embassy-time-driver 0.2.1
# if you do it anyway you should also do this: git commit -am 'update to `embassy-time-driver` v0.2.1'

pushd embassy-time
cargo release patch --execute
popd
# no need for this since it's just a patch: ./release/bump-dependency.sh embassy-time 0.4.1
# if you do it anyway you should also do this: git commit -am 'update to `embassy-time` v0.4.1'

pushd embassy-embedded-hal
cargo release patch --execute
popd
./release/bump-dependency.sh embassy-embedded-hal 0.4.0
git commit -am 'update to `embassy-embedded-hal` v0.4.0'

pushd embassy-rp
cargo release minor --execute
popd
./release/bump-dependency.sh embassy-rp 0.5.0
git commit -am 'update to `embassy-executor-macros` v0.5.0'

git push --tags # push all version commits & tags

[rursprung]

oh, hold off: what's missing here is a release of embassy-executor! just realised that this is also a dependency of embassy-rp and some of the others - it'd be a shame if that'd not be included!

EDIT: done!

[jamessizeland]

looking forward to this release! My examples are broken until embassy-embedded-hal goes to embassy-sync 0.7 🙏

[bugadani]

run the following steps from latest main (after the merge) in a clean repo:

To be fair this is still quite daunting. If this is the best that is possible right now, the esp-hal release code is available for copying 🙃 The tooling is plan-based, involves several steps just to make sure it's hard to mess up. An example release PR looks like this. Seems to work well enough for us, but I didn't take the time to generalize it for other projects, however I wonder if we could spare Dario a few minutes of work each time.

[rursprung]

To be fair this is still quite daunting.

it's the same as was always done for embassy - except that it's now cargo release $level --execute instead of vim Cargo.toml + set correct new version + cargo publish. i'd love to say way more automation here. one thing which prevents this is the fact that the crates target different architectures and are thus not in a common workspace. otherwise that'd be even easier. there are also things like release-plz which i haven't tested yet but i think as long as cargo doesn't support multi-target workspaces (waiting for https://github.com/rust-lang/cargo/issues/9406) there's not much improvement possible here?

The tooling is plan-based, involves several steps just to make sure it's hard to mess up. to be fair, cargo release also offers to run individual steps. e.g. probe-rs does this (see their workflow)

from an outside-in look the single biggest hurdle in embassy preventing more frequent releases seems to be assembling changelogs since that's only being done at the time one wishes to do a release, requiring to dig through the whole git commit history for the affected crate(s), trying to piece together what was done and which of these things are changelog-worthy and what should be described (so that the changelog offers more than a simple git-log would tell you - otherwise you wouldn't need a changelog to begin with). i do hope that this will eventually get automated in a similar manner to what probe-rs is doing and i hope that this might happen centrally rather than having a home-grown tool here (as probe-rs has): https://github.com/crate-ci/cargo-release/issues/231#issuecomment-2953651577

if there's anything that can be done to help move this release out of the door please shout! i think there are various people here looking forward to them

An example release PR looks like this. Seems to work well enough for us, but I didn't take the time to generalize it for other projects, however I wonder if we could spare Dario a few minutes of work each time.

[antonok-edm]

requiring to dig through the whole git commit history for the affected crate(s), trying to piece together what was done and which of these things are changelog-worthy and what should be described (so that the changelog offers more than a simple git-log would tell you - otherwise you wouldn't need a changelog to begin with). i do hope that this will eventually get automated in a similar manner to what probe-rs is doing and i hope that this might happen centrally rather than having a home-grown tool here (as probe-rs has)

FWIW, a couple of other approaches I've seen:

• require PRs to also include corresponding updates to the changelog file
• use GitHub labels and milestones at merge-time to annotate PRs with eligibility for release notes (there can be milestones like embassy-rp v0.5.0 and labels like Release Notes/Include or Release Notes/Exclude)

[rursprung]

rebased & updated the embassy-executor changelog to include #4266 (it's the only changelog-worthy PR merged since i created this PR here).

[kpfleming]

• require PRs to also include corresponding updates to the changelog file

Random drive-by comment as I was reading this PR since I'm also interested in new releases... don't use a single file to gather changes. A number of projects I help manage do this, and it's a constant nightmare of merge conflicts, and if your branch protection policies require PR branches to be 'up to date' before merging, then it's even worse.

Any mechanism which supports changelog fragments in a directory, which then combines them into a changelog file for release, is far superior.