build SDK releases from an opt-out release branch on top of master

[turadg]

What is the Problem Being Solved?

Our release branches are made by cherry picking commits from master (opt-in to changes). We've come far enough along that we can invert this to being opt-out. That is, branch off master and then apply commits that revert any changes deemed unsafe.

Tasks

Beta Give feedback

1. Identify what behavior in master is not safe or yet feasible to deploy

Description of the Design

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

[aj-agoric]

Placed into @iomekam backlog since he is release manager for 16,

[dckc]

looks like as of upgrade-16, we're still doing opt-in:

• Cherry-pick upgrade-16 commits #9545
• Upgrade-16 cherry-picks round 2 #9625
• Upgrade-16 cherry-picks round 3 #9640
• chore: More upgrade-16 cherry-picks #9675
  plus
• fix(cosmos): don't rerun store migrations on upgrade #9683

this is based on looking at git log --graph --oneline origin/master origin/dev-upgrade-16
with master = 3c66f4b and dev-upgrade-16 = 0df76a7

[iomekam]

Our intention was to abide by going with an opt-out flow. However, by the time we started trying to perform the merging, the release branch wasn't in an ideal spot, and doing the merging would have been more overhead. Specifically, there were some changes that landed that would have complicated the merging.

We still released from master, we just did so by cherry-picking instead of merging.