Edition bump process planning

[Kixunil]

We should figure out how to do edition changes while minimizing churn - waste least amount of time on rebases/conflict resolution.

Identified time wasters/risks:

• There are unrelated open PRs - these would have to be rebased
• Some people may have WIP changes locally, not published in PRs
• Some people may intend to make changes unaware of edition change efforts

The edition bump is mostly automatic but the codebase is complicated enough to require a few manual interventions. I view it as mostly easy.

Proposed process

0. Right after 0.28 release we update our README, CONTRIBUTING, and perhaps other place to inform contributors of upcoming events. We give one week grace period for people to finish WIP non-trivial changes and submit PRs. People who don't mind rebasing their PRs may mark them as drafts.
1. After one week we forbid opening new PRs against master until the process is finished. Critical fixes, if any, may be submitted against a new 0.28.x branch.
2. We focus on reviewing and merging as many non-draft PRs as reasonable.
3. Once all relevant PRs are merged one of us will make a PR bumping edition. It should have three commits: changing edition and making it compilable, edition style fixes, clippy fixes.
4. After merging we will focus on things from the TODO list, large-scale first.
5. Once there are no outstanding large-scale changes we allow new PRs.
6. We finish the TODO list.
7. We consider other fixes if needed and start release process for 0.29.0

Rationale

• One week period gives time for people with WIP changes to submit them. This could be abused for starting new things but I think it's OK to rely on honesty here.
• Disallowing new PRs will prevent "resource starvation"
• Because of partially automated nature of edition bump it should be easier to redo it after PRs are merged rather than rebasing all PRs.

Unresolved questions

• We should make the no-new-prs period as short as possible - how can we optimize this?
• Is one week sufficient? E.g. someone could get sick...
• Is the one week period even needed? Maybe nobody has WIP local changes.

[tcharding]

Thanks for thinking about this, I totally agree with your sentiment but I'm inclined to think that we should favour a more brutal approach - just do the MSRV bump immediately and let folk rebase as they wish, any red PRs wont be merge candidates anyways. This has the benefit of being a natural filter for old stale PRs

We have to do the whole stack so an alternate approach could be:

0. Taproot release drops
1. Merge anything in rust-bech32, rust-bitcoinconsensus, bitcoin_hashes that is approved and ready to merge
2. Merge the edition-2018 PRs in rust-bech32, rust-bitcoinconsensus, bitcoin_hashes (these are all ready to go, inclu. version bump)
3. rust-secp256k1: Update, review, merge edition-2018 PR (@elichai this ones yours [0]).
4. rust-bitcoin: Update, review, merge edition-2018 PR (this one is @Kixunil)

[0] - I rebased it locally just now to see how hard it is and its a bit painful but less than 30 minutes work.

[Kixunil]

just do the MSRV bump immediately and let folk rebase as they wish

Please no. I'm one of the affected and I'd rather redo #635 than rebase my other stuff. Rebases due to bullshit reasons drain my motivation to contribute to Open Source and I wouldn't be surprised if I'm not alone.

[tcharding]

Fair point, I can cop this. No matter how we end up doing this, if there ends up being some painfully boring task because of it please holla at me, I'm happy to do it for you - I consider myself very fortunate to be able to spend my whole day on this library so am more than willing to put some hours into boring tasks if it removes the burden from others. (Not that that is an excuse for my process suggestion to cause boring work but just offering.)

[tcharding]

It should have three commits: changing edition and making it compilable, edition style fixes, clippy fixes.

For mine I did

• Update CI and README
• Update to version 2018 and make build pass
• clippy as separate patches as required

[Kixunil]

CI + README as a separate initial step is fine.

[tcharding]

After merging we will focus on things from the TODO list

Some folk want to do Taproot improvements too so it might be a bit messy for the next little while. Perhaps we just have to release a bunch of times as we organically try to push forwards?

[Kixunil]

I wouldn't block other improvements as long as there aren't large-scale changes being planned.

[tcharding]

Hey @Kixunil, just wanted to mention that I've thrown up a number of PRs that require an MSRV bump including removing Rust 1.29 from CI. I've been sure to not do anything that is invasive and will hamper your current PRs.

[Kixunil]

I'm fine with bumping MSRV independently. I'm not sure if throwing a bunch of new PRs in is helpful at this point. Unless you already had them locally of course. :)

[tcharding]

I did not have them locally, it just never occurred to me that we could bump the MSRV in a separate PR to doing the massive-automated-change PR and I got excited that there was some small progress I could make while waiting for other PRs to merge. I often get excited and rush into things, one day I'll learn :)

[Kixunil]

OK, just hold off for now as the more PRs are opened the later edition bump will happen (or you will rebase a lot).

[tcharding]

So far we have only discussed edition bump in rust-bitcoin crate, whats the plan for the rest of the stack? Are we better to start at the bottom, at the top, or just use chaos method? One idea is to start at the bottom and for each crate do:

• Merge edition update PR
• Build/test locally the dependent crates using path dependency
• Release crate on crates.io
• Then move up the stack to the next crate, where the edition bump PR can now include dependency bump of the ones lower down the stack

[Kixunil]

IMO the order doesn't matter as long as the order of releases is from dependencies to bitcoin.

[apoelstra]

Agreed -- in most cases we've needed to start at the bottom so that rust-bitcoin's deps were updated before rust-bitcoin, but in this case I don't think it matters at all.

[tcharding]

Sick! Merge like its your job @apoelstra!

[tcharding]

Friendly request please maintainers, please consider reviewing the open 'enable edition 2018' PRs across the stack. This update is kind of a blocker for other work, would be great to get it in. So far we have got bitcoin_hashes done and rust-miniscript. Still to go are:

• Edition 2018 #983
• Update the code to edition 2018, and update dependencies rust-secp256k1#331
• Enable edition 2018 rust-bitcoinconsensus#34
• Enable edition 2018 rust-bech32#57

[tcharding]

On @Kixunil's list above we are currently at step (3), the PR does not however include clippy fixes, I left them out to hasten review and merge.