I can update it in case we are aiming straight to 3.0.0-alpha.0 instead.

I would also suggest using the 3.0.0-alpha.0 version instead, letting users know where we are thinking of going next.

I think it will need a rebase on master.

What is needed here IMO is to just cut a new branch called release/2.2 and merge this commit on it.

Once this is done, master is free to continue and merge breaking changes, and non-API-breaking commits will need to be cherry-picked between the two branches master and release/2.2.

As a side note, I think there should be a release/2.1 branch. This ensures we can push patches to both the 2.0 and 2.1 feature releases independently.

Do you anticipate a user needing a version like 2.1.x after 2.2.0 is released? I assumed that we would only maintain the last major release branch (2.0), including everything that's compatible with 2.x, and cut a release when ready, but maybe I'm confused. At least that's how things worked with the old release/0.30 branch.

Yeah you absolutely can (just push fixes to the latest feature release of a major release), but I think in general having branches for each allows you to do it if you wanted to. It also makes it explicit that patches only go on the latest feature release if that's the only branch that gets a bump (say release/2.2) and all other don't get the patch (release/2.1 and release/2.0 don't get commits added). The other thing it does is simplify digging into code when people say they use "X" release. I always have a branch with all commits for that release ready. Checking out the tag does the same really, but branches are nice to work with.

Of course this is just my 2 sats. On bdk-ffi you can find all feature releases get their own branches. But honestly it doesn't impact the workflow immensely, I just figured I'd share/point it out.

I'll ACK this whether it's for merging on release/2.0 or release/2.2 no problem!

I'm fine with renaming the branch to release/2.2, in fact just calling it release/2.x would make the most sense to me.

On bdk-ffi you can find all feature releases get their own branches

Yes but releases below 1.0 are semver incompatible and can be treated as the major version for all intents and purposes.

Ok I see you have a release/1.1 and release/1.2 on bdk-ffi. Like you said devs can also check out a tag. Still, in this instance I'm not sure it would makes sense to backport a fix to both 2.1 and 2.2 branches. edit: but I'll re-read your comment.

ACK 8b97a08

Done in e43e597

Yep agree with all your points above. It's mostly cosmetic, and in reality you're unlikely to port patches back. I like our workflow, but don't take my comment + approach as the only one!