Development workflow

Lawnchair utilizes a tiered workflow to balance development velocity with system stability. All pull requests (PRs) must target the 16-dev branch unless otherwise specified.

Change tiers

The complexity and risk of a change determine the review protocol.

Tier	Definition	Examples	Protocol
Trivial	Zero risk of regression.	Typos, documentation, style fixes.	Commit directly to the active branch.
Simple	Functionally isolated changes with low risk.	Single-file bug fixes, minor UI polish.	Create PR, assign reviewer, enable auto-merge.
Medium	Changes affecting multiple components.	New settings screens, drawer search providers.	Detailed PR, requires core team review.
Major	High-risk, core architectural changes.	Android version rebases, subsystem rewrites.	Detailed PR, mandatory formal approval required.

Commit conventions

We follow the Conventional Commits specification. Commits should use the following format: type(scope): subject.

Allowed types include: feat, fix, style, refactor, perf, docs, test, and chore.

Versioning scheme

Lawnchair version codes utilize a five-part structure to ensure compatibility and track development stages.

1. Android major version

2. Android minor version

3. Development stage (00: Dev, 01: Alpha, 02: Beta, 03: RC, 04: Release)

4. Development version

5. Revision number

The following table lists the development stages used by Lawnchair:

Stage	Denoted by
Development	00
Alpha	01
Beta	02
Release Candidate	03
Release	04