Frequency Git Workflow

Overview

Source Diagram: https://docs.google.com/drawings/d/1GyvodIcZ3AfrfmpgK465N369Lu-F41Ni-__Gvk4p6iQ

This page describes Git branching workflow employed by the Frequency team during development and release cycles. This workflow has 4 types of branches:

Number	Branch Name	Type	Branch Pattern	Purpose
1	Developer Branch	Short-Lived	[issue#]-[brief-descriptive-name]	a.k.a "feature branch", used to develop new features and make other changes for the upcoming releases
2	Release Branch	Long-Lived	release-v[x.x.x*]	Frequency release tied to the specific Polkadot release version, e.g. v0.9.29, v0.9.30, etc., e.g. release-v0.9.29, release-v0.9.30, release-v0.9.30-1, etc.
3	Next Branch	Long-Lived	origin/main	Represents the next version under development, i.e. a release candidate
4	Hot Fix Branch	Short-Lived	[issue#]-[brief-descriptive-name]	These hot fix branches are necessary to act immediately upon an undesired status of one of the current releases (Rococo and/or Mainnet)

Once a long-lived branch is created, it can stay in the repo forever. In other words, there is no time limitation on the lifecycle of such branch.

Change Management

To work on something new:

1. Create a new developer branch off main and give it a descriptively name starting with the story number (ie: 504-retire-msa-id, , 323-upgrade-runtime-v0.29.0`, etc.)
2. Commit to that branch locally and regularly push your work to the same named branch on the server
3. When you need feedback or help, or you think the branch is ready for merging, open a pull request
4. After someone else has reviewed and signed off on the feature, you can merge it into main

Releases

Coming soon...

Hot Fixes

Coming soon...