Skip to content

docs: refer to semantic-release instead of release-please #1097

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
frankieyan merged 3 commits into from
Jul 16, 2026
Merged

docs: refer to semantic-release instead of release-please #1097

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9010747
docs: refer to semantic-release instead of release-please
frankieyan Jul 16, 2026
49654a4
docs: note perf: and any breaking type as releasing prefixes
frankieyan Jul 16, 2026
43b928f
docs: remove style: from the commit type examples
frankieyan Jul 16, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/PULL_REQUEST_TEMPLATE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,5 +21,5 @@ Feel free to leave unchecked or remove the lines that are not applicable.
- [ ] Reviewed and approved Chromatic visual regression tests in CI

<!--
_Note:_ versioning is handled by [release-please](https://github.com/googleapis/release-please) action, based on the PR title.
_Note:_ versioning is handled by [semantic-release](https://github.com/semantic-release/semantic-release), based on the PR title.
-->
6 changes: 4 additions & 2 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -109,11 +109,12 @@ For generic React Testing Library patterns (component tests, hook tests, provide
## Commits and PRs

- PR titles must follow [conventional commits](https://www.conventionalcommits.org/): `feat:`, `fix:`, `chore:`, `refactor:`, `test:`, `docs:`, etc.
- `feat:` triggers a minor version bump, `fix:` triggers a patch, `feat!:` or `fix!:` triggers a major (breaking)
- Versioning is automated by release-please based on PR title
- `feat:` triggers a minor version bump, `fix:` and `perf:` trigger a patch, any type with `!` or a `BREAKING CHANGE:` footer triggers a major (breaking)
- Versioning is automated by semantic-release based on PR title

@doistbot doistbot Jul 16, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 semantic-release's configured commit analyzer reads Git commit messages, not GitHub PR metadata. PR titles can differ from the resulting commits (for example with rebase merges), so describe versioning in terms of conventional commit messages and align the README guidance with that source of truth.

@frankieyan frankieyan Jul 16, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@doistbot we squash commits in this repo with the commit message defaulting to the PR title. Rarely will the final message deviate so I think this should be clear enough.

@doistbot doistbot Jul 16, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes “PR title” a practical shorthand for this repository, since squash merges normally carry it into the resulting commit. However, semantic-release itself doesn’t read GitHub PR metadata: release.config.js uses @semantic-release/commit-analyzer, which analyzes commit messages on main.

I’d keep the wording technically precise and mention the workflow explicitly:

Versioning is automated by semantic-release based on conventional commit messages. With squash merges, the resulting commit message normally defaults to the PR title.

That preserves the current practice without implying the PR title is semantic-release’s source of truth.

@frankieyan frankieyan Jul 16, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are technically right, but I'm gonna overrule this and say this is ok 😎 (let's see if your human colleague disagrees)

- Pre-commit hooks run Prettier, ESLint, and React Compiler tracking - do not skip them

<!-- shared-config:agents -->

# AGENTS

> [!WARNING]
Expand Down Expand Up @@ -220,4 +221,5 @@ When asked to create a pull request, follow this mandatory process:
## Enforcement

These guidelines are **non-negotiable**. Deviation from this process constitutes a failure to follow core instructions. When in doubt, ask for clarification.

<!-- /shared-config:agents -->
27 changes: 12 additions & 15 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -203,34 +203,31 @@ When you open a GitHub PR, you'll notice the "UI Review" and "UI Tests" CI steps

# Releasing

This project uses [release-please](https://github.com/googleapis/release-please) to automate version management and package publishing.
This project uses [semantic-release](https://github.com/semantic-release/semantic-release) to automate version management and package publishing.

## How it works

1. Make your changes using [Conventional Commits](https://www.conventionalcommits.org/):
- Any type below with an added `!` suffix (e.g. `feat!:`, `fix!:`) or a `BREAKING CHANGE:` footer for breaking changes (major version bump)
- `feat:` for new features (minor version bump)
- `fix:` for bug fixes (patch version bump)
- `style:` for code style changes
- `perf:` for performance improvements
- `perf:` for performance improvements (patch version bump)
- `refactor:` for refactoring code
- `test:` for adding/updating tests
- `build:` for build/dependency changes
- `docs:` for documentation changes
- `ci:` for CI changes
- `revert:` for reverting previous commits
- `feat!:` or `fix!:` for breaking changes (major version bump)
- `chore:` for maintenance tasks (NOTE: these are not included in the changelog)

2. When commits are pushed to `main`:
- Release-please automatically creates/updates a release PR
- The PR includes version bump and changelog updates
- Review the PR and merge when ready

3. After merging the release PR:
- A new GitHub release is automatically created
- A new tag is created
- The `publish` workflow is triggered
- The package is published to npm and GitHub Packages
- Storybook documentation is automatically updated
Any type can carry an optional scope, e.g. `feat(button):` or `perf(tooltip)!:`.

2. When a PR is merged to `main`, the [Package Release](.github/workflows/publish-package-release.yml) workflow runs and semantic-release:
- Reads the merged commit's conventional-commit type to determine the version bump
- Updates `CHANGELOG.md`, `package.json`, and `package-lock.json`, and commits them back to `main`
- Creates a new tag and GitHub release
- Publishes the package to npm and GitHub Packages

A merge triggers a release only when it includes a type marked with a version bump above; otherwise nothing is published.

The storybook hosted on GitHub pages will be automatically updated on each push to `main`. If there's a problem, try running the action manually from the [Actions settings](https://github.com/Doist/reactist/actions).
Loading