Branching @ Miden - node

[drahnr]

Context

Recently we discussed alternatives, @marti proposed 3 options, and I proposed a variation of one of them.

Refresher - Status Quo

We have two branches, main representing testnet, and next representing devnet.

At some point in time we merge main into next to ensure we have
all changes rom main to next. And vice verse to start a new cycle.
This works OK up to a certain point of change-rate
where merging main to next causes a lot of conflicts, usually caused by either
next being far ahead in the sense of breaking changes applied, but also main
getting "hotfixes" that are relevant to code that doesn't exist in next anymore.
It's both error-prone and time intense.

We also chose a development target per feature/PR depending on urgency, either being merged
first into next or into main. Changing this is similarly painful given a sufficent
delta between next and main.

            15.0    16.0    16.1     v16.2
            v       v       v        v
●──●───●────●───●───●───●───●────●───●───●───●───.. next ~ devnet
 ╲         ╱      ╲    ╱        ╱     ╲
●─●───●───●───●────●──●────●───●───●───●───●───.. main ~ testnet
  ^                ^               ^   ^
 14.0             15.1          15.2   16.3

Ensuring Consistency

Consistency is ensured as long as the merge is done correctly, which becomes challenging the further
next and main deviate from one another.

CI / CD

We do manual deployments, where we do have a 1:1 mapping between devnet and testnet to main and next.
The deployment itself is however brittle and comes with guaranteed downtime.

---

Alternative / Option 4

Instead of having two branches, we branch off at an arbitrary, agreed on point in next
and create a new release-${major.minor}.x release branch. It's going to be the source
for all patch releases of ${major.minor}. Once the branch is not needed anymore, we can simply
stop updating it. At no point in time we have to merge next or release-${major.minor}.x ever again.
The git history becomes a true DAG in respect to commit histories outside of PR merges.

●──●───●───●───●───●───●───●───●───●───●───●───.. next
    ╲               ╲
      ╲                o────────────────o───x release-0.14.x
        ╲              14.0a            14.0
          o───────o─────o───o───x release-0.13.x
          ^       ^     ^   ^
          13.0a0  13.0 13.1 13.2

Ensuring consistency

Since this does not cover an automatism to transfer all changes, we have to have a deliberate manual flow of changes from next to the relevant feature branches.

It can be summed up in one rule:

There must be an agreement, that unless something is a hotfix that is only required for a specific branch,
next must receive the fix first, and then a second PR can be openend against any release branch
carrying the changeset - with adaptations to the relevant branch, and a backlink to the original PR for next.
It allows for easy tracking which branches received a certain fix and which did not.

CI / CD

The flow here requires a per-branch pipeline. The definitions of devnet and testnet abecome indirections that we can change atomically
by redirecting URLs from one live network to another. It comes with additional complexity.

[sergerad]

There must be an agreement, that unless something is a hotfix that is only required for a specific branch,
next must receive the fix first, and then a second PR can be openend against any release branch
carrying the changeset

For clarity and alignment - I expect to never need to merge main (current next) and release branches. Cherry picking commits will always suffice. Notwithstanding (probably rare) cases where a merge is equivalent to cherry-picking due to the nature (and lack of) recent changes in main.

[drahnr]

100% aligned