This repo coordinates releases of Gofasta across its three product repos:
| Repo | Module path | What it ships |
|---|---|---|
gofasta |
github.com/gofastadev/gofasta |
The library: 27 pkg/* packages projects import. |
cli |
github.com/gofastadev/cli |
The gofasta binary: project scaffolding, code generation, dev pipeline. |
website |
— | Documentation site and landing page. |
The three repos are versioned and released independently in normal operation. This repo is the single source of truth when they ship together as a coordinated release.
QA_TESTING_GUIDE.md— the QA policy. Risk taxonomy, test types, exploratory charters, release gates, the ship rule.COMPATIBILITY.md— the version compatibility matrix. Declares whichcliversions are compatible with whichgofastaversions. Independent versioning, documented compat windows. Enforced nightly bycompat-matrix.yml.CADENCE.md— release cadence policy. Patch / minor / major / coordinated cadences, security-patch SLOs by CVSS tier, and support windows.RELEASING.md— operational playbook. One-time setup before your first release, the per-release procedure, and the automation arc that documents which manual steps are scheduled to graduate to CI or built-in CLI commands.COMMUNITY.md— community guide for indie developers, contributors, and small teams. Where conversations happen, what to expect when filing a bug or PR, the maintenance-team-of-one acknowledgment, sustainability planning.REFERENCES.md— annotated bibliography of works that informed the QA policy, release coordination process, compatibility model, cadence policy, and tooling choices..github/ISSUE_TEMPLATE/coordinated-release.md— the per-release tracking template. Open a new issue from this template for each release; it walks the sequenced gates..github/workflows/compat-matrix.yml— the nightly + PR-triggered compatibility matrix regression workflow. Scaffolds a fresh project for every still-supported(cli, gofasta)row inCOMPATIBILITY.mdand builds it.qa/sessions/— exploratory testing session notes, one Markdown file per session.releases/— user-facing release notes, one Markdown file per shipped version.
Gofasta is currently maintained by one person; sustainability planning — release cadence, security SLOs, the solo-to-team transition, and the automation arc that retires manual steps as the project matures — is documented across CADENCE.md, RELEASING.md, and COMMUNITY.md. Reviewers evaluating Gofasta for institutional adoption should read those three together for the full picture.
The full procedure is in RELEASING.md. At the top level:
- Open a release issue in this repo from the Coordinated release template. Title it
Release: cli vX.Y.Z + gofasta vA.B.C(or just one repo if only one is shipping). - Fill in scope and risks. Which repos at which versions/branches; rescore the Risk Matrix for the actual edits in this cycle.
- Walk the gates in order: gofasta library → cli ↔ gofasta integration handshake →
COMPATIBILITY.mdPR → cli release → website. Each gate ends with a 🛑 step that must not be skipped. - Run exploratory charters on the highest-tier P1 areas. Commit session notes under
qa/sessions/. - Tick exit criteria. When every gate, P1 test, and exit-criteria item is checked, ship.
- Tag and ship in order: gofasta first, then cli, then website. Verify install on a clean machine.
- Retro. Fill in the retro section. Anything painful gets a
release:retrolabel in its source repo for the next cycle.
For your very first release, follow the Part A one-time setup in RELEASING.md before opening the tracking issue. There's a five-day timeline for v0.1.0 specifically.
The QA framework, release templates, and session notes don't belong to any single product repo — they govern all three. Keeping them here means:
- Cross-repo session notes (e.g., a charter that exercises gofasta + cli together) have one home.
- Release issues that reference outward to all three repos live in a neutral location.
- The QA methodology is discoverable as one document, not buried inside cli or gofasta history.
MIT.