Prepare beta version

[tcharding]

Somehow we need to get this crate updated to use a bitcoin beta release either bitcoin 0.33-beta or the soon-to-be-released (TM) bitcoin 0.34.0-beta). Could use master until that release happens.

We discussed version numbering of the beta release here: rust-bitcoin/rust-bitcoin#5648

I had a bit of a go already: #874. The thing is this PR is hard to create and almost impossible to review. But we need to push this forward somehow.

• How can we make the upgrade more manageable to review?
• What branch should the PR target i.e., are we going to maintain a separate branch for beta releases and non-beta releases. Said another way is dev here in miniscript going to continue in parallel for bitcoin 0.32 and bitcoin-beta?
  • Yes: leads to way more maintenance
  • No: leaves bitcoin 0.32 users behind

High level question: Do you think @apoelstra that this issue can be worked on by a newer dev or is it something you, me, and/or Sanket need to do? (Not that I'm at all qualified in this repo.)

[apoelstra]

No, I don't think that a newer dev can work on this. I think the right decision is to have a separate branch and accept the maintenance burden. Hopefully bitcoin can get out of beta reasonably soon.

[apoelstra]

To be clear -- "reasonably soon" on the timeline of rust-miniscript, which (for example) has had a near-total-rewrite branch I've been maintaining for the better part of 2 years :)

[tcharding]

No, I don't think that a newer dev can work on this.

Righto, my task then. I had a shower thought how we can do this. I can prepare a set of patches, which each do a single change and do not build then after review we can squash them and git range-diff to check nothing changed. I'll have to do tons of rebasing and probably whinge a whole bunch but then at least you will have some chance of being able to confidently review. Be forwarded though that I'm going to need your help on the script tag changes, I'll be doing best guess that's about all. Everything else I should be on top of though.

I think the right decision is to have a separate branch and accept the maintenance burden

So we run two parallel branches of development. Does every change have to go in both or do we come up with some idea/policy/guarantee about what is being done in each?

[tcharding]

near-total-rewrite branch I've been maintaining for the better part of 2 years :)

Perhaps this needs to all go in before we try to do the beta? But on the otherhand the beta release is needed last week already?

[apoelstra]

Perhaps this needs to all go in before we try to do the beta?

I would prefer this, yes, unless the point of the beta is just to test rust-bitcoin and to be thrown away.

[tcharding]

Oh so do we do this?

1. Have branch for testing that depends on bitcoin beta (we have this at Upgrade bitcoin to the upcoming 0.33.0-beta release #874) and don't both rebasing it.
2. In the next six months until non-beta-bitcoin comes out do near-total-rewrite
3. After non-beta-bitcoin comes out start maintaining multiple branches, one for depend-on-bitcoin-0.32 and one for depend-on-bitcoin-latest

[apoelstra]

Yes, except (2) will take much longer than six months, unless we can get Sanket back online or otherwise have a second maintainer who can review stuff like #895.

[tcharding]

Closing. We have a plan now to try to create iterative releases of rust-bitcoin to assist the upgrade path.