I tried to add label:"release notes mention" to aid this. But did not do so consistently.

Nice idea, who do you imagine adds that label, the author wanting a mention, reviewers thinking its important enough, or the merger?

I suggest removing #1114 from requirements since it doesn't affect consumer code.

@tcharding I suggest the label is added by whoever thinks it should be and if there's disagreement we can discuss. I'd also like two more labels: no-release-notes-mention and aggregate-release-notes-mention first one to skip PR completely when making release notes, the second to just put e.g. "Various documentation improvements" - should have label for appropriate category. Then CI check that makes it mandatory for a PR to have exactly one label so that we don't forget.

Agreed, I don't think it's important who adds these labels -- they're unlikely to be controversial and if they are, that seems evidence enough to put something into the release notes :)

Then CI check that makes it mandatory for a PR to have exactly one label so that we don't forget.

Doing this implies that the author must add the label, I'd like to prevent burdening newer contributors with tasks that are just there to help with administrative tasks (writing the release notes).

If the label is optional it at least means we give authors a chance to request that their work gets mentioned. Any PRs that don't get tagged just get left out of the release notes, no big deal.

I've added the two additional labels you requested @Kixunil

implies that the author

It doesn't, it implies a reviewer has to do that. However, I just realized it's possibly annoying, since a non-member would have to trigger CI re-run after the label was added.

burdening newer contributors with tasks that are just there to help with administrative tasks

From my experience of contributing to LND where they have very similar rule - just it has to be in a file, it's not a big deal if not for exactly these problems:

• You can't reliably predict PR id, so you have to make a PR first and then immediately amend it with release notes addition
• Multiple parallel PRs always cause rebases

Ideally GitHub would have a native tool to resolve that but it could be done with this trick:

• Require 3 approvals
• Upon PR opening a bot immediately checks labels and requests changes, possibly the author can add the label himself with a command similar to rustbot
• After label is added the bot approves the PR.

From my experience contributing to Rust lang, these bots are pretty nice and can do multiple things including welcoming new contributors, assigning reviewers...

I request that if #994 gets merged then also #1129 gets merged.

I added #1137 to required because it'd greatly suck to not have TryFrom and have inherent try_from method since the trait was added after MSRV bump.
I have also moved #1129 to required because it fixes Sequence not having stringly conversions. Without them original code sequence: some_str.parse()? would be annoying to rewrite while with them it'll continue to work fine.

Can we also add #1151 which includes a bug fix and some cleanups

I've triggered re-run of CI.

All, green, almost ready. However I just realized maybe #1144 would be good to include. Pros/cons:

• Not merging gives more time to people to update, we still remove maintenance cost by merging shortly after release.
• Merging is final "no longer supported" act that removes any potential "bug fix" issues/PRs; we would just wontfix that though.
• Joining breaking changes into single release makes point releases easier but probably non issue with clean removal of stuff.
• Not merging can make release sooner.

I did go through all PRs and added missing milestone/API break markers. We should make the list of breaking changes visible.

Sure, I'll try to sneak in #1144 today.

It's been deprecated forever and AFAIK never had any value, I see no reason to keep it around for another cycle.

Should we update our rust-bitcoinconsensus dep as well?

@apoelstra definitely! Good catch. I'm confused about the versioning though. I think cargo treats things with - as development versions and will not allow later version that's compatible. Can you explain why there's such versioning?

@Kixunil rust-bitcoin/rust-bitcoinconsensus#40 everything before the - is the Bitcoin Core version.

As far as I'm concerned this is a problem with crates.io/cargo and there's not much we can do about it.

@tcharding can you change this PR to bump the bitcoinconsensus version?

@tcharding can you change this PR to bump the bitcoinconsensus version?

I did it as a separate PR: #1165

This raised the question, do we want to update bitcoinconsensus to use bitcoin core 21 (taproot release) and depend on that before this release or does that not matter? For the record I have an open PR to update bitcoinconsensus but its broken, working on fixing it now.

Maybe we should just go ahead and release with bitcoinconsensus 0.20.2-0.5.0 because I cannot get the upgrade to bitcoin core 21 working.

Agreed. I'd like to have 21 but I don't think it's a blocker, and if it's nontrivial to do then we can let it slip.

I added P-high label to #1165, so we can get that through. I'll push update to release notes and rebase soon as that one merges. Then we should be about right to go, anything else we are missing?

@tcharding merged #1165 . I think we are good to go

Rebased and added chagelog entry for bitcoinconsensus dependency upgrade - lets go!

Oh, can we get #1171 in? It's trivial and would be nice to combine it with having Sequence.

OK, the two remaining checklist questions are #1106 :

• Assess the semver trick (which should actually be done after release ... in fact we should go back and see if we can't semver-trick the last 5 or 10 releases to ease migration)
• See if we should write an upgrade guide (I'm going to punt on this for now, let's build up to having sane processes)

Will wait for one more ACK then let's go!

I suspect that semver trick is too complex for these changes but I'm willing to review if someone figures it out. Also upgrading guide doesn't feel required since we were pretty careful about things like people accidentally unwrapping stuff. (Maybe that part can only be decided by the number of "I can't upgrade" issues.)

Agreed that we won't be able to e.g. semver-trick Transaction since we introduced these new Sequence/LockTime types that can't possibly be made compatible with old versions of rust-bitcoin.

But we could semver-trick e.g. the entire bip32 module, which has barely changed at all for several versions.

Hmm, partial semver trick may be useful too. I'm not sure how much it helps though.

@Kixunil i think we could partial-semver-trick Script and Address and bip32 say, so then projects that depend on both bitcoin and miniscript would have a very good chance of continuing to work even if users updated bitcoin but not miniscript.

Oh, Address sounds good indeed, also Amount I have crates that use only those, so I guess others may as well.

BTW @tcharding could we have an ACK on this? I don't wanna publish without your awareness.

ACK 110b5d8

Thanks!

Let's go!

Published, signed and tagged.