Action item from requiem/doc/postmortem475066.
In 14.1.0-rc.0 for tooling, the RC failed to release due to a new package, so the main branch was never bumped to 14.2.0-next.0. This left the repository in an inconsistent state, where 14.1.x had the 14.1.0-rc.0 release which is ahead of the 14.1.0-next.x release previously in main. ng-dev appropriately discovered this issue and failed on subsequent executions lest it do the wrong thing, but this required a manual version bump in main to address which is not obvious.
The proper solution is probably to just not fail RC releases, but that's tricky to guarantee. If and when an RC cut fails, we should define some kind of fallback behavior such as:
- Doing the
main bump anyways (which might be risky given that RC branch could be in a weird state).
- Roll back the RC version bump (also might be risky for the same reason).
- Print a message that
main and RC are now conflicting and what options the caretaker has to resolve it (least risky automation, but caretakers can get confused or potentially do the wrong thing in response).
Action item from requiem/doc/postmortem475066.
In
14.1.0-rc.0for tooling, the RC failed to release due to a new package, so themainbranch was never bumped to14.2.0-next.0. This left the repository in an inconsistent state, where14.1.xhad the14.1.0-rc.0release which is ahead of the14.1.0-next.xrelease previously inmain.ng-devappropriately discovered this issue and failed on subsequent executions lest it do the wrong thing, but this required a manual version bump inmainto address which is not obvious.The proper solution is probably to just not fail RC releases, but that's tricky to guarantee. If and when an RC cut fails, we should define some kind of fallback behavior such as:
mainbump anyways (which might be risky given that RC branch could be in a weird state).mainand RC are now conflicting and what options the caretaker has to resolve it (least risky automation, but caretakers can get confused or potentially do the wrong thing in response).