Tags and releases are the owner's call; no repo document tells him when to tag. Model: opus-5-5
2.1 KiB
Workflow
git pullnextand cut a branch from it — one branch per issue, namedissue-<N>-<slug>. Never branch frommain.- Do the work as one commit whose title ends with
(closes #N). - Record no finished work in this file. What landed is recorded on the tracker
and in
git log, where each commit title names the issue it closes. - Run
make fmt, thenmake check. A feature branch may be red;nextandmainmay not. - Rebase onto current
nextimmediately before pushing — other branches land onnextcontinuously — and re-runmake checkafter resolving, because a clean textual merge can still break the build. - Push the branch and open one PR per issue with base
next. Never basemain. - An independent reviewer who did not write the change gates the merge. On a
passed review the PR is squash-merged into
next. nextis the branch for the next milestone. It is kept green and mergeable tomainat any moment, without notice.mainreceives exactly one PR per milestone, fromnext. Releases are tagged frommain.
Status
pre-1.0, working towards the 1.0.0 milestone. The milestone is in flight on
next; its next -> main PR is
#388. make build produces
dist/chrome/ and dist/firefox/ with DEBUG compiled off, and checks them
against the build's own receipt to hold exactly the regular files and symlinks
that build emitted.
The backlog lives on the
Gitea tracker, which is
authoritative; this file does not duplicate it. Full policy file set present.
Real-browser end-to-end suites (make test-e2e for Chrome,
make test-e2e-firefox for Firefox) sit alongside make check, which runs the
tests, static analysis and the formatting check, and .gitea/workflows/e2e.yml
runs both of them on every push.
Next Step
The open issues on the 1.0.0 milestone.
Future Steps
Only work that has no issue of its own belongs here; everything else is on the tracker.