Frequency Git Workflow
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.
To work on something new, 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.)
Coming soon...
Coming soon...