Changelog

Overview

This is the git policy used for all Liqwid Labs projects. This is loosely based on the MLabs git policy, but a couple changes in wording and strictness have been applied.

<aside> ❓ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

</aside>

Rules

Branches and PRs

All projects outside of Liqwid Libs have the following primary branches:

`staging`	An unstable branch used to collect works-in-progress. May not have passing CI at all times.
`main`	A stable branch ready for downstream integration. Must have passing CI at all times.
`testnet`	A stable branch known to work on the current testnet all the way downstream. Must have passing CI at all times.
`mainnet`	A stable branch known to work on the current mainnet all the way down stream. Must have passing CI at all times.

The goal is to always have known-working commits in the testnet and mainnet branches.

The PR workflow is as follows
- If staging is used in the repository:
  - Features MUST target staging.
    - The naming scheme MUST follow <username>/<feature>
  - It’s RECOMMENDED that staging gets merged into main weekly or biweekly. staging → main
  - Urgent fixes MAY go straight through to main, and then MUST be back-ported to staging later. hotfix → main → staging
- Merging to testnet or mainnet must first happen downstream before the same changes can be merged upstream.
  - For instance, if an onchain feature is added in liqwid-onchain, it begins in staging and moves to main once it is ready to be integrated into liqwid-offchain in staging. When the feature reaches main in liqwid-offchain, it starts in staging on lq-app. Once it reaches testnet in lq-app, the upstream commits in liqwid-offchain and liqwid-onchain should also be moved to testnet.
When merging PRs maintainers MUST use git merge, and not git rebase
- Repositories SHOULD enforce this explicitly in the settings
- Contributors MAY git rebase within a PR in order to clean up the commit log.

GitHub settings page where disabling squash and rebase can be disabled or PRs.

Maintainers MUST NOT use squash/--amend or force pushes on main or staging, even for fixing commit history. “Pretty” commit history does not take precedence over preserving a consistent append-only history.
- In a feature branch force pushing is allowed in order to clean commit history, however.

Commit messages

Contributors MUST use concise but descriptive commit messages.
The first line of a commit MUST NOT be longer than 72 characters.

<aside> 💡 This is the line limit for GitHub’s log view.

</aside>
Multi-line commits
- The first line MUST always be sufficient to understand the purpose of the commit.
- Additional lines MAY add additional information that isn’t present in the first line.
- A single empty line MUST be placed between the head and the body of the commit.