Releases are cut automatically by semantic-release from commit messages, so the prefix you use decides whether a release happens and how the version changes.
Format: type: subject, or type(scope): subject.
| Prefix | Version bump | Use for |
|---|---|---|
fix: |
patch (1.2.3 → 1.2.4) |
A bug fix users would notice |
perf: |
patch | A performance improvement |
feat: |
minor (1.2.3 → 1.3.0) |
New functionality |
build: chore: ci: docs: refactor: style: test:
These land on main without publishing a gem. Use them for anything with no
user-facing change — test fixes, CI tweaks, internal refactors. They are still
included in the next release's notes.
Either add ! after the type, or a BREAKING CHANGE: footer. Both produce a
major bump (1.2.3 → 2.0.0):
feat!: remove deprecated sideload API
feat: replace sideload API
BREAKING CHANGE: `allow_sideload` no longer accepts a :scope option.
The ! works with a scope too: feat(adapters)!: ...
Describe what breaks and what to do instead — the footer text is published in the release notes verbatim.
- Only the commit prefix matters, not the PR title, unless the PR is squash-merged with the title as the commit subject.
- The prefix must be lowercase and followed by
:—Fix: thingandfix:thingare both unparsed, and an unparsed commit never triggers a release. - If nothing since the last tag is
fix:,perf:,feat:, or breaking, no release is cut. That is expected.
bundle exec rspecThe Rails integration specs are gated behind an environment variable and are
silently skipped without it — a plain rspec run reports success while
covering none of the ActiveRecord adapter:
BUNDLE_GEMFILE=gemfiles/rails_8_0_graphiti_rails.gemfile \
APPRAISAL_INITIALIZED=1 \
bundle exec rspec spec/integration/rails/Lint with:
bundle exec standardrb