You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently branch Release from the commit before the "cut" commit, and RC is branched from the "cut" commit. Because the base of these two branches differ, it's not possible to fast-forward merge RC to Release at the end of the testing cycle, and we end up with a merge commit having two parents. Those two parents make a more complicated history where it may be unclear where the release actually came from because the left parent will be the Main branch so the release version tag could be mistaken to be referring to the change before the "cut" commit.
We should change the automation to cut both the Release and RC branches from the "cut" commit.
We would then have the problem that if no fixes are done on RC then it wouldn't be possible to have a PR from RC to Release to run automations for the actual release when testing is done. That can be solved by having the cut-automation push an empty commit to RC immediately after creating it so that there's always guaranteed to be something on RC that can be merged to Release at the end.
The text was updated successfully, but these errors were encountered:
We currently branch
Release
from the commit before the "cut" commit, andRC
is branched from the "cut" commit. Because the base of these two branches differ, it's not possible to fast-forward mergeRC
toRelease
at the end of the testing cycle, and we end up with a merge commit having two parents. Those two parents make a more complicated history where it may be unclear where the release actually came from because the left parent will be theMain
branch so the release version tag could be mistaken to be referring to the change before the "cut" commit.We should change the automation to cut both the
Release
andRC
branches from the "cut" commit.We would then have the problem that if no fixes are done on
RC
then it wouldn't be possible to have a PR fromRC
toRelease
to run automations for the actual release when testing is done. That can be solved by having the cut-automation push an empty commit toRC
immediately after creating it so that there's always guaranteed to be something onRC
that can be merged toRelease
at the end.The text was updated successfully, but these errors were encountered: