From 5bc145fe2fea49af7d73058241d47a9cd84d57d9 Mon Sep 17 00:00:00 2001 From: Matheus Robert Lichtnow Date: Sat, 7 Mar 2026 11:31:08 -0300 Subject: [PATCH] docs: add release process documentation to CONTRIBUTING.md Document the automated release-please workflow, version bumping rules, and npm publishing steps. --- CONTRIBUTING.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e431ab8..ac714ca 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -85,3 +85,19 @@ This creates a new numbered `.sql` file in `src/migrations/`. Migrations are pla 4. Open a PR against `main` CI will run tests against PostgreSQL 13 through 18, lint the code, verify the build output, and check that all commit messages follow the conventional format. + +## Releases + +Releases are automated via [release-please](https://github.com/googleapis/release-please). The process works as follows: + +1. PRs are merged into `main` with conventional commit messages. +2. On each push to `main`, release-please scans the new commits and either creates or updates a single open "Release PR". This PR bumps the version in `package.json`, updates `CHANGELOG.md`, and updates `.release-please-manifest.json`. If no conventional commits (`feat:`, `fix:`, etc.) are found, nothing happens. +3. The Release PR stays open and accumulates changes as more PRs are merged. Only `feat:` and `fix:` commits trigger version bumps -- `chore:`, `docs:`, and `test:` commits are excluded from the changelog. +4. When you are ready to cut a release, merge the Release PR. Release-please then creates a GitHub Release with a git tag (e.g., `v1.2.0`). +5. To publish to npm, manually trigger the **Publish** workflow from the Actions tab. Run it with dry-run enabled first to verify the package contents, then run it again with dry-run disabled to publish. + +Version bumps follow [semver](https://semver.org/): + +- `fix:` commits bump the patch version (e.g., 1.0.0 -> 1.0.1) +- `feat:` commits bump the minor version (e.g., 1.0.0 -> 1.1.0) +- `BREAKING CHANGE:` in the commit body or `!` after the type bumps the major version (e.g., 1.0.0 -> 2.0.0)