From https://www.erisian.com.au/bitcoin-core-dev/log-2025-09-18.html#l-365
0<fanquake> sjors: how are you planning to handle version in the multiprocess subtree going forward?
1<fanquake> *versioning
2<Sjors[m]1> fanquake: do you mean versioning of the interface or of the multiprocess dependency?
3<fanquake> I'm guessing release branches to match Core? Otherwise I'm wondering what the plan is if you need to land bugfixes from multiprocess that wont apply to release branches, due to api changes or similar
4<Sjors[m]1> For the latter we should probably tag whatever is in v30
5<fanquake> We also don't generally backport subtree updates, so this would also be new for multiprocess
6<sipa> if a subtree has a bugfix that matters, it does seem reasonable to backport it
7<fanquake> Sure, but that might have to be selective, rather than a full pull
8<sipa> yeah, makes sense
9<fanquake> so by default isn't a clean backport
10<fanquake> so just wondering what the plan is there, and if anything is going to be done to track things upstream in the multiproess repo
11<Sjors[m]1> Maybe ryanofsky has a specific plan. I would imagine indeed having a seperate branch to track minimal changes if anything needs to be backported to v30.1+
12<fanquake> Ok, can leave it up to you and him to figure out going forward
I think there are two questions here:
- Which libmultiprocess changes should be backported to bitcoin release branches?
- What steps should be used to backport the changes if any are backports?
IMO the short term answer to (1) should be either all of the changes or none of them. At least for the next few weeks I don’t think there will be any libmultiprocess changes that aren’t either safe or desirable to backport, like bugfixes, documentation improvements, CI improvements, and error handling improvements. I think the only changes to avoid backporting might be PRs that add new features like #32387 (adding windows support) or https://github.com/bitcoin-core/libmultiprocess/pull/209 (turning on newer cmake features). If/when PRs like these are merged, it will make sense to create a libmultiprocess v1 stable branch corresponding to the bitcoin v30 branch, and more stable branches going forward, as fanquake suggested in IRC.
I’m less sure about answer to (2), especially if subtree updates have never been backported before. I guess two options are either backporting subtree update PR’s like #33412 using the normal backport process, or submitting separate subtree update PRs directly to the bitcoin release branches? I’m not sure which of these might more desirable or work better with tooling.