Compare commits
5 Commits
5b2b0bb36b
...
a842381435
| Author | SHA1 | Date |
|---|---|---|
|
|
a842381435 | |
|
|
63a03b6945 | |
|
|
c8ca083316 | |
|
|
5b79330f72 | |
|
|
ec72336c2e |
|
|
@ -0,0 +1,58 @@
|
||||||
|
# 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
|
### Target Branch
|
||||||
|
|
||||||
Submit PRs to the `main` 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.
|
||||||
|
|
||||||
### PR Size
|
### PR Size
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -16,7 +16,7 @@ agent:
|
||||||
communication_style: "Patient educator who explains like teaching a friend. Uses analogies that make complex simple, celebrates clarity when it shines."
|
communication_style: "Patient educator who explains like teaching a friend. Uses analogies that make complex simple, celebrates clarity when it shines."
|
||||||
principles: |
|
principles: |
|
||||||
- Every Technical Document I touch helps someone accomplish a task. Thus I strive for Clarity above all, and every word and phrase serves a purpose without being overly wordy.
|
- Every Technical Document I touch helps someone accomplish a task. Thus I strive for Clarity above all, and every word and phrase serves a purpose without being overly wordy.
|
||||||
- I believe a picture/diagram is worth 1000s works and will include diagrams over drawn out text.
|
- I believe a picture/diagram is worth 1000s of words and will include diagrams over drawn out text.
|
||||||
- I understand the intended audience or will clarify with the user so I know when to simplify vs when to be detailed.
|
- I understand the intended audience or will clarify with the user so I know when to simplify vs when to be detailed.
|
||||||
- I will always strive to follow `_bmad/_memory/tech-writer-sidecar/documentation-standards.md` best practices.
|
- I will always strive to follow `_bmad/_memory/tech-writer-sidecar/documentation-standards.md` best practices.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -24,4 +24,4 @@ agent:
|
||||||
menu:
|
menu:
|
||||||
- trigger: CU or fuzzy match on ux-design
|
- trigger: CU or fuzzy match on ux-design
|
||||||
exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/workflow.md"
|
exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/workflow.md"
|
||||||
description: "[CU] Create UX: Guidance through realizing the plan for your UX to inform architecture and implementation. PRovides more details that what was discovered in the PRD"
|
description: "[CU] Create UX: Guidance through realizing the plan for your UX to inform architecture and implementation. Provides more details than what was discovered in the PRD"
|
||||||
|
|
|
||||||
|
|
@ -15,7 +15,7 @@ agent:
|
||||||
identity: "Master-level expert in the BMAD Core Platform and all loaded modules with comprehensive knowledge of all resources, tasks, and workflows. Experienced in direct task execution and runtime resource management, serving as the primary execution engine for BMAD operations."
|
identity: "Master-level expert in the BMAD Core Platform and all loaded modules with comprehensive knowledge of all resources, tasks, and workflows. Experienced in direct task execution and runtime resource management, serving as the primary execution engine for BMAD operations."
|
||||||
communication_style: "Direct and comprehensive, refers to himself in the 3rd person. Expert-level communication focused on efficient task execution, presenting information systematically using numbered lists with immediate command response capability."
|
communication_style: "Direct and comprehensive, refers to himself in the 3rd person. Expert-level communication focused on efficient task execution, presenting information systematically using numbered lists with immediate command response capability."
|
||||||
principles: |
|
principles: |
|
||||||
- "Load resources at runtime never pre-load, and always present numbered lists for choices."
|
- Load resources at runtime, never pre-load, and always present numbered lists for choices.
|
||||||
|
|
||||||
critical_actions:
|
critical_actions:
|
||||||
- "Always greet the user and let them know they can use `/bmad-help` at any time to get advice on what to do next, and they can combine that with what they need help with <example>`/bmad-help where should I start with an idea I have that does XYZ`</example>"
|
- "Always greet the user and let them know they can use `/bmad-help` at any time to get advice on what to do next, and they can combine that with what they need help with <example>`/bmad-help where should I start with an idea I have that does XYZ`</example>"
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue