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.). Direct commits to main` are not allowed.
2. Commit to that branch locally and regularly push your work to the same named branch on the server.
3. Run tests locally
4. When you need feedback or help, or you think the branch is ready for merging, open a pull request. This will trigger "Verify PR" CI workflow which will execute multiple checks on the code changes in the PR.
5. If CI fails, address reported issues and push a new commit to remote. This will trigger a new "Verify PR" workflow run. Repeat this step until all jobs in CI are passing successfully.
6. After someone else has reviewed and signed off on the feature, you can merge your PR into main

Releases

When code in main is ready to be released (e.g. after runtime upgrade) a new release branch will be created. This release branch will have a version in its name tied to the official Polkadot release. Pushing commits to this branch will not automatically publish a new release. To trigger the latter, a deploy will need to tag a commit with a vx.x.x* release tag and push it to the remote. Examples of the release tags are:

• v0.29.0 - corresponds to Polkadot release v0.29.0
• v0.29.0-1 - additional change 1 to the existing v0.29.0 Frequency release
• v0.29.0-2 - additional change 2 to the existing v0.29.0 Frequency release
• v0.30.0 - corresponds to Polkadot release v0.30.0

When a release is triggered on a given release branch, all artifacts will be built and published. This gives the node owner a flexible choice to use any artifact from any published release version.

Hot Fixes

Coming soon...