What it is
One row per build (1.0.0, 1.1.0, 1.1.1-hotfix). Records version, release date, changelog, known bugs, QA status (pending / in progress / passed / failed / skipped), and target platforms.
When to use it
- Logging the build that went to QA last Friday so the team knows it exists.
- Tracking which builds failed certification and why.
- Pinning a "current build" reference for playtest sessions.
- Recording known bugs that ship in a hotfix because the alternative was worse.
How to use it
- 1Click "+ New Build" — version, name, target platforms.
- 2Write the changelog (or paste from your engine's release notes).
- 3Update QA status as testing progresses.
- 4Note known bugs that survive the release.
Tips you should know
- →Build Tracker is the QA-facing view; Build Log is the user-facing changelog. They're separate intentionally.
- →Platforms field is a multi-select — a build targeting "PC + Mac" appears in both filters.
- →QA status flow is one-way (pending → passed/failed) — re-test by creating a new build entry.
- →Cross-link risks to builds — "this build mitigates risk X" is an audit trail worth keeping.