DEP0 - A branching and naming convention across all projects

[alexwykoff]

Note: OUT OF DATE, read this instead: https://github.com/dxos/gravity/blob/master/docs/content/process/branching.md

Proposal

Documentation

To be codified in long term storage via https://github.com/dxos/gravity/tree/main/docs/content/process/branching.md

Problem Statement

• DXOS projects need a consistent and concise convention to follow regarding branches and their relation to daily work vs more stable releases.

Proposed Solution

• Developers MUST submit their work via pull requests to the main branch. ((currently named 'master' due to grandfathered convention. duplication and migration of default branch is recommended)) Only pull requests which pass CI and review should be merged. This presumes and requires an established CI system. The CI will use https://github.com/googleapis/release-please to manage publishing and semver.
• Commit messages should follow https://www.conventionalcommits.org/en/v1.0.0/
• The channel which will be published via this method shall be considered release
• The latest version of the main branch at any time shall be considered master
• Channels will follow the convention established of rising fidelity master -> dev -> beta -> release (ex: https://github.com/brave/brave-browser/wiki/Release-Channel-Descriptions)
• Each step in channel layers expectations of quality.
• For starting projects, a concatenated set of Master -> Release channels is sufficient.
• Release conditions are managed per-project in their docs/content/process/release.md which will specify any non-automated constraints.

[telackey]

Implicit in this, but I think worth making explicit, is that all publishing, whether to organizational repositories (eg, Verdaccio) or public (eg, NPM) must be done by automated processes. No manual builds.

[alexwykoff]

Tracking work elsewhere : https://github.com/dxos/sdk/issues/201