16e417c88e
- Add VERSIONING.md documenting 0.1.x/0.2.x branch strategy - Add docs/CHANGELOG.md with release notes for v0.1.0-v0.2.1 - Update CONTRIBUTING.md: fix master->main, add develop branch - Closes #120
67 lines
1.8 KiB
Markdown
67 lines
1.8 KiB
Markdown
# Contributing
|
|
|
|
## Workflow
|
|
|
|
1. Create a branch for your work: `git checkout -b fix/issue-N-name` or `git checkout -b feat/feature-name`
|
|
2. Make changes and commit with clear messages
|
|
3. Open a Pull Request for review
|
|
4. Do not merge directly to `main` or `develop` for reviewable changes
|
|
5. After approval, squash and merge
|
|
|
|
## Guidelines
|
|
|
|
- Use clear, descriptive commit messages
|
|
- Keep PRs focused and reasonably sized
|
|
- Document any non-obvious decisions
|
|
- Test changes before submitting
|
|
- See [VERSIONING.md](VERSIONING.md) for backport compatibility rules
|
|
|
|
## Branches
|
|
|
|
### Primary Branches
|
|
|
|
- `main` — stable 0.1.x releases, production-ready code
|
|
- `develop` — experimental 0.2.x work, next major version
|
|
|
|
### Feature Branches
|
|
|
|
- `fix/*` — bug fixes
|
|
- `feat/*` — new features
|
|
- `docs/*` — documentation updates
|
|
- `refactor/*` — code refactoring (no behavior change)
|
|
|
|
## Branch Model
|
|
|
|
```
|
|
main (0.1.x stable)
|
|
└── v0.1.0, v0.1.1, v0.1.2, ...
|
|
|
|
develop (0.2.x experimental)
|
|
└── (next major version work)
|
|
```
|
|
|
|
### Which Branch to Target?
|
|
|
|
| Change Type | Target Branch | Backport? |
|
|
|-------------|---------------|-----------|
|
|
| Bug fix | `main` | N/A |
|
|
| Documentation | `main` | N/A |
|
|
| New feature (backport-compatible) | `main` | Can cherry-pick to `develop` |
|
|
| Experimental feature | `develop` | No |
|
|
| Breaking change | `develop` | No |
|
|
|
|
## Backport Compatibility
|
|
|
|
Before merging, consider if your change is backport-compatible:
|
|
|
|
- **YES**: Bug fixes, docs, adding new optional inputs
|
|
- **NO**: Changing behavior, changing defaults, removing features
|
|
|
|
See [VERSIONING.md](VERSIONING.md) for full policy.
|
|
|
|
## Release Process
|
|
|
|
1. Bug fixes and docs → directly to `main`
|
|
2. New features → `develop` or feature branches → `develop`
|
|
3. When `develop` is stable enough → merge to `main` for release
|