Compare commits
3 Commits
63a03b6945
...
a7b213d5f0
| Author | SHA1 | Date |
|---|---|---|
Alex Verkhovsky
|
a7b213d5f0 | |
|
Alex Verkhovsky
|
9a33db2042 | |
Adam Biggs
|
b815410904 |
58
BRANCHING.md
58
BRANCHING.md
|
|
@ -1,58 +0,0 @@
|
|||
# Branching Strategy
|
||||
|
||||
BMad uses a **stable-branch** model: `main` is the development branch, and numbered branches hold stable releases that receive only cherry-picked fixes.
|
||||
|
||||
```
|
||||
main ●───●───●───●───●───●───●───●──────► 7.0, ...
|
||||
\ \
|
||||
v6 ●───●───● \ patches only
|
||||
│ │ │ \
|
||||
v6.0.0 v6.0.2 \
|
||||
│ \
|
||||
v6.0.1 \
|
||||
\
|
||||
v6.1 ●───●───● patches only
|
||||
│ │
|
||||
v6.1.0 v6.1.1
|
||||
```
|
||||
|
||||
Every minor version (6.0, 6.1, ...) ships from `main` as its own stable branch. Only patches are cherry-picked onto stable branches.
|
||||
|
||||
This pattern is used by Node.js, Go, and Python — adapted here for a project that ships an npm CLI.
|
||||
|
||||
---
|
||||
|
||||
## The Three Lanes
|
||||
|
||||
| Branch | Purpose | What goes here | Gets tagged? |
|
||||
| --- | --- | --- | --- |
|
||||
| `main` | Next version development | All new work, via PRs | Pre-release only (`X.Y.0-alpha.N`) |
|
||||
| `v<major.minor>` (e.g., `v6`, `v6.1`) | Stable release maintenance | Cherry-picks from `main` only | Yes — `vX.Y.Z` |
|
||||
| Forks | Experimental work | Anything | Never |
|
||||
|
||||
### Rules
|
||||
|
||||
1. **All fixes must land on `main` first**, then get cherry-picked to the stable branch.
|
||||
2. **One stable branch at a time.** When a new major version ships, the old one stops receiving patches.
|
||||
|
||||
---
|
||||
|
||||
## Lifecycle
|
||||
|
||||
**New version:** Feature branches target `main` (see [CONTRIBUTING.md](CONTRIBUTING.md)). Pre-release tags cut from `main` as needed.
|
||||
|
||||
**Stable release:** When ready, cut a stable branch from `main` (e.g., `v6`, `v6.1`), tag it, bump `main` to the next version. From that point, `main` is the next release.
|
||||
|
||||
**Patch:** Fix lands on `main` via normal PR. Cherry-pick the merged commit to the stable branch. Tag the patch release.
|
||||
|
||||
**Retirement:** When the next major ships, the old stable branch is left as-is. Tags remain as permanent references.
|
||||
|
||||
---
|
||||
|
||||
## FAQ
|
||||
|
||||
**Why not Git Flow?**
|
||||
Git Flow adds a `develop` branch and release branches per version. For one active version and a small team, that's overhead without benefit.
|
||||
|
||||
**Why cherry-pick instead of merging `main` into stable?**
|
||||
Cherry-picking isolates fixes; merging would pull incomplete features from `main`.
|
||||
|
|
@ -73,7 +73,7 @@ After searching, use the [feature request template](https://github.com/bmad-code
|
|||
|
||||
### Target Branch
|
||||
|
||||
Submit PRs to the `main` branch unless you are patching a stable release branch. See [BRANCHING.md](BRANCHING.md) for details on the stable-branch model.
|
||||
Submit PRs to the `main` branch. We use [trunk-based development](https://trunkbaseddevelopment.com/branch-for-release/): `main` is the trunk where all work lands, and stable release branches receive only cherry-picked fixes.
|
||||
|
||||
### PR Size
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
mode: primary
|
||||
name: '{{name}}'
|
||||
description: '{{description}}'
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,12 @@
|
|||
---
|
||||
name: '{{name}}'
|
||||
description: '{{description}}'
|
||||
---
|
||||
|
||||
Execute the BMAD '{{name}}' task.
|
||||
|
||||
TASK INSTRUCTIONS:
|
||||
|
||||
1. LOAD the task file from {project-root}/{{bmadFolderName}}/{{path}}
|
||||
2. READ its entire contents
|
||||
3. FOLLOW every instruction precisely as specified
|
||||
|
|
|
|||
|
|
@ -1,10 +1,12 @@
|
|||
---
|
||||
name: '{{name}}'
|
||||
description: '{{description}}'
|
||||
---
|
||||
|
||||
Execute the BMAD '{{name}}' tool.
|
||||
|
||||
TOOL INSTRUCTIONS:
|
||||
|
||||
1. LOAD the tool file from {project-root}/{{bmadFolderName}}/{{path}}
|
||||
2. READ its entire contents
|
||||
3. FOLLOW every instruction precisely as specified
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
---
|
||||
name: '{{name}}'
|
||||
description: '{{description}}'
|
||||
---
|
||||
|
||||
|
|
@ -7,6 +8,7 @@ Execute the BMAD '{{name}}' workflow.
|
|||
CRITICAL: You must load and follow the workflow definition exactly.
|
||||
|
||||
WORKFLOW INSTRUCTIONS:
|
||||
|
||||
1. LOAD the workflow file from {project-root}/{{bmadFolderName}}/{{path}}
|
||||
2. READ its entire contents
|
||||
3. FOLLOW every step precisely as specified
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
---
|
||||
name: '{{name}}'
|
||||
description: '{{description}}'
|
||||
---
|
||||
|
||||
|
|
@ -7,6 +8,7 @@ Execute the BMAD '{{name}}' workflow.
|
|||
CRITICAL: You must load and follow the workflow definition exactly.
|
||||
|
||||
WORKFLOW INSTRUCTIONS:
|
||||
|
||||
1. LOAD the workflow file from {project-root}/{{bmadFolderName}}/{{path}}
|
||||
2. READ its entire contents
|
||||
3. FOLLOW every step precisely as specified
|
||||
|
|
|
|||
Loading…
Reference in New Issue