dxos / gravity

System testing frameworks.
GNU Affero General Public License v3.0
1 stars 1 forks source link

Branch name / build scheme #25

Closed dboreham closed 3 years ago

dboreham commented 3 years ago

We would like to have, for each git repository:

  1. Stable release branches (release_1_1, release_1_2) that are built (ideally automated, but manually triggered) into versioned package public releases. Branch rather than tag because these branches may contain multiple commits done as part of both pre-release stability work, and post-release minor fixes. Never requires private dependencies.
  2. "Master" branch that contains code that is "the most recent release_x_x plus subsequent ongoing compatible development", and will usually for the basis for the next release branch when it is made. Developers can expect the code on master to pass tests and be usually fully functional (possibly broken for short periods due to integration bugs, mistaken commits etc). CI enabled to check build and run unit tests should be run on every push. Never requires private dependencies. PRs for release bugfixes and minor enhancements are made against master.
  3. "Canary" branches used for major new interface breaking and experimental development. Typically there is only one active canary branch. CI enabled to check build, unit tests, plus automated package publish to private registry. Canary branch CI builds pull dependencies from a private registry on a specified canary channel, allowing composite builds across multiple monorepos under concurrent development. PRs for incremental development of major new interface breaking and experimental development are made against the appropriate canary branch.