Sort-of-merge-back: v3.12.3
into v3.13.x
#6669
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
v3.12
has been patched:v3.12.3
. This patch should be propagated tov3.13.x
, and also tomain
.I created this branch using:
By propagating to
v3.13.x
first, we should be able to preserve the original commits and avoid the inevitable merge conflicts that come when usinggit cherry-pick
1. Sincev3.12.x
andv3.13.x
share a common history, you can see that the only difference is the one we want - the commits from the new patch.Once the patch release of
v3.13
is complete, we can then finish with a normal merge-back fromv3.13.x
tomain
.Footnotes
the alternative: standard merge-back
v3.12.x
intomain
. How to then add the desired patch tov3.13.x
? Must not mergemain
into3.13.x
sincemain
includes many other commits that occurred post-3.13-release. Only remaining option is tocherry-pick
, which gives the commit(s) new SHA(s), and they conflict whenv3.13.x
is merged-back intomain
. ↩