Skip to content

Require checking parent feature branches before dependent work #1227

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
enaboapps merged 1 commit into from
Oct 28, 2026
Merged

Require checking parent feature branches before dependent work #1227

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ The frozen C# application is not maintained in this repository. Do not reintrodu

## Workflow

- Start every change with a GitHub issue and a scoped branch from current `main`.
- Start every change with a GitHub issue and a scoped branch. Before creating the branch, fetch remotes and inspect open pull requests and active feature branches for a parent feature branch that already contains work this change depends on. For dependent work, branch from that parent's latest head and target the pull request at the parent branch; identify the parent pull request in the description. Otherwise, branch from current `main` and target `main`. Rebase and retarget stacked pull requests when their parent merges, preserving only the scoped child changes.
- Never create a GitHub issue without a milestone. Select or create the appropriate milestone first and include it in the issue creation request; assigning it afterward is not allowed. This applies to every issue, including bugs, chores, release preparation, and follow-up work. Verify the milestone on the created issue before continuing.
- Choose the milestone from the **next** open release after the current shipped version. Prefer `package.json` / `src-tauri/Cargo.toml` as the shipped version; confirm with the newest published tag including prereleases (`gh release list`), not GitHub's "Latest" release badge (that can point at an older stable while RC tags are current). Do not put new work on a milestone whose version is already shipped, even if that milestone is still open. If the user names a target RC, use that open milestone instead.
- When a version is released, close its milestone if it has no open issues. If open issues remain, move unfinished work to the next open milestone (or ask) before closing the shipped one.
Expand Down
Loading