Version Management and Branching Strategy

[nholland94]

This page intends to serve as a living document and discussion forum for our version management and branching strategy for the repository. We will keep this document up to date as the set of branches we are actively maintaining changes overtime. Please feel free to leave a comment as feedback.

Branching Strategy

In the Mina repository, there are 2 long running branches that will be kept around permanently:

• master: The latest mainnet release. This branch is always code-frozen and is updated when we perform new mainnet releases.
• compatible: The staging branch for soft fork releases. The code in this branch is always compatible with what is currently deployed to mainnet, and is where work is landed in preparation for the next mainnet soft fork release.

In addition to these branches, there will also be temporary branches we keep around based on ongoing work outside of mainnet and soft fork releases. Whenever we have a testnet that we are supporting, we will keep a branch around with the same name associated with that testnet release. Similar to master, these branches will be code-frozen, so we will only publish new releases or perform hotfixes to them. In addition to these, we will also have separate branches for any hard fork versions we are actively developing. Similarly, these branches will be named after the hard fork releases code name.

The default branch will be set to whatever version has the most development focus at a given point in time. When the majority of development effort is spent maintaining the active hard fork version on mainnet, compatible will be the default branch. When the development is focused on the next upcoming hard fork version, the associated hard fork branch will be the default.

Currently Maintained Testnets

• rampup: The public rampup network where we are deploying an early version of the 2.0 hard fork for community testing.

Currently Maintained Hard Fork Upgrades

• berkeley: The 2.0 hard fork upgrade which adds zkApps to the Mina protocol.

Branch Set Relations

In order to keep our branches clean, we maintain a strict series of superset relations between the branches we are actively maintaining. This is to say that if, for some branches a and b, b ⊇ a, then b contains all of the commits in a and possibly some additional ones. As such, whenever branch a gets updated, we intend to also merge a back into b so as to maintain the superset relationship. This heavily reduces merge conflicts across divergent versions of the software that we maintain, and provides a clarity in how changes can be propagated to multiple versions at once.

The current branch relations are: berkeley ⊇ rampup ⊇ compatible ⊇ master

[mimoo]

What about fixes in compatible like this one that don't intend to be part of rampup nor berkeley?

[bkase]

In practice, this means the workflow for submitting a change that you want to live in multiple branches is to:

1. Open only one PR on the Least Upper Bound branch according to the relation above (ie. if you wanted the change on compatible and rampup and berkeley, you just open it on compatible)
2. If necessary you fix potential conflicts with other branches as CI asserts forces you to do
3. The change propagates towards the "larger" branches by the merging process that will soon be automated

@nholland94 feel free to integrate this into the above document