|
| 1 | +# Contributing |
| 2 | + |
| 3 | +## Commit Messages |
| 4 | + |
| 5 | +This project uses [Conventional Commits](https://www.conventionalcommits.org/). The release tooling reads commit messages to determine version bumps and generate the changelog, so the format matters. |
| 6 | + |
| 7 | +``` |
| 8 | +<type>(<optional scope>): <description> |
| 9 | +
|
| 10 | +<optional body> |
| 11 | +
|
| 12 | +<optional footer> |
| 13 | +``` |
| 14 | + |
| 15 | +Common types: |
| 16 | + |
| 17 | +| Type | Changelog section | Version effect (pre-1.0) | |
| 18 | +|------------|----------------------------|---------------------------| |
| 19 | +| `feat` | Features | minor bump (0.x → 0.x+1) | |
| 20 | +| `fix` | Bug Fixes | patch bump | |
| 21 | +| `perf` | Performance Improvements | patch bump | |
| 22 | +| `docs` | Documentation | patch bump | |
| 23 | +| `refactor` | Code Refactoring | patch bump | |
| 24 | +| `chore` | Miscellaneous | patch bump | |
| 25 | +| `build` | Build System | patch bump | |
| 26 | +| `test` | Tests | patch bump | |
| 27 | +| `ci` | *(hidden)* | no bump | |
| 28 | + |
| 29 | +### Breaking changes |
| 30 | + |
| 31 | +Append `!` to the type, or add a `BREAKING CHANGE:` footer, to signal a breaking change. This |
| 32 | +produces a major version bump once the project reaches 1.0; before 1.0 it produces a minor bump. |
| 33 | + |
| 34 | +``` |
| 35 | +feat!: remove deprecated --output flag |
| 36 | +
|
| 37 | +BREAKING CHANGE: the --output flag was removed; use --format instead |
| 38 | +``` |
| 39 | + |
| 40 | +## Development |
| 41 | + |
| 42 | +```sh |
| 43 | +cargo fmt --all --check |
| 44 | +cargo clippy --all-targets -- -D warnings |
| 45 | +RUSTDOCFLAGS='-D warnings' cargo doc --no-deps |
| 46 | +cargo test --all-targets |
| 47 | +cargo test --doc |
| 48 | +``` |
| 49 | + |
| 50 | +## Release Process |
| 51 | + |
| 52 | +Releases are automated via [release-please](https://github.com/googleapis/release-please). |
| 53 | + |
| 54 | +### How it works |
| 55 | + |
| 56 | +1. Every merge to `main` runs the Release Please GitHub Action. |
| 57 | +2. The action inspects commits since the last release and opens (or updates) a **Release PR** that: |
| 58 | + - bumps the version in `Cargo.toml` |
| 59 | + - updates `CHANGELOG.md` |
| 60 | +3. When a maintainer is ready to ship, they **merge the Release PR**. |
| 61 | +4. Merging the Release PR triggers the `publish` job, which runs `cargo publish` to crates.io. |
| 62 | + |
| 63 | +No manual tagging or version editing is needed — everything flows from commit messages. |
| 64 | + |
| 65 | +### Pre-1.0 versioning |
| 66 | + |
| 67 | +Until the crate reaches `1.0.0`, the bump rules are conservative: |
| 68 | + |
| 69 | +- A `feat` commit bumps the **patch** version (not minor). |
| 70 | +- A breaking change bumps the **minor** version (not major). |
| 71 | + |
| 72 | +This matches the project's current stability expectations. The rules will switch to standard semver |
| 73 | +once `1.0.0` is tagged. |
| 74 | + |
| 75 | +### Retrying a failed publish |
| 76 | + |
| 77 | +If the release tag was created but `cargo publish` failed (network blip, crates.io outage, etc.), |
| 78 | +trigger the workflow manually without creating a duplicate release: |
| 79 | + |
| 80 | +1. Go to **Actions → Release → Run workflow**. |
| 81 | +2. Check **Skip release-please, run publish directly**. |
| 82 | +3. Click **Run workflow**. |
0 commit comments