This document describes how releases are managed for ralph-starter.
ralph-starter uses an automated release process based on GitHub Actions. Releases are triggered when a release PR is merged to main.
Feature PR → main → Release PR → Tag → GitHub Release → npm publish
- Create a feature branch from
main - Make your changes
- Open a PR to
main - If your PR includes changes to
src/orpackage.json, it automatically gets thecandidate-releaselabel
When a PR with the candidate-release label is merged:
- A release branch (
release/vX.Y.Z) is automatically created - Version in
package.jsonis bumped based on conventional commit prefixes:feat:orfeat(scope):→ minor bump (0.1.0 → 0.2.0)fix:,chore:, etc. → patch bump (0.1.0 → 0.1.1)BREAKINGor!in title → major bump (0.1.0 → 1.0.0)
- A release PR is automatically opened
When the release PR is merged:
- Git tag
vX.Y.Zis created and pushed - GitHub Release is published with auto-generated release notes
- Package is published to npm with appropriate tag:
- Stable versions →
latesttag - Prerelease versions (e.g.,
1.0.0-beta.1) →betatag
- Stable versions →
Standard semver versions: 0.1.0, 1.0.0, 2.3.1
npm install -g ralph-starterVersions with prerelease identifiers: 0.2.0-beta.1, 1.0.0-alpha.3
npm install -g ralph-starter@beta
# or specific version
npm install -g ralph-starter@0.2.0-beta.1Use the Stable Release GitHub Actions workflow when you want to promote from beta to an official stable release.
- Go to Actions → Stable Release → Run workflow
- Set
versionto a stable semver (no prerelease suffix), for example0.2.0 - Optionally provide curated
release_notesmarkdown (or leave empty to auto-consolidate beta changelog entries) - Merge the generated
release/vX.Y.ZPR intomain Releaseworkflow creates tagvX.Y.Z, publishes GitHub release, and publishes npm withlatest
- Keeps stable release notes curated from beta iterations
- Uses the same CI build/test gates as normal releases
- Avoids manual tagging mistakes
If you need to release manually:
# 1. Ensure you're on main and up to date
git checkout main
git pull origin main
# 2. Update version
pnpm version patch # or minor/major
# 3. Push with tags
git push origin main --tags
# 4. The release workflow will detect the tag and publishChangelogs are automatically generated during releases based on commit messages. To ensure good changelogs:
- Use Conventional Commits
- Write clear, descriptive commit messages
- Reference issues when applicable (
Fixes #123)
| Type | Description | Changelog Section |
|---|---|---|
feat |
New features | Features |
fix |
Bug fixes | Bug Fixes |
docs |
Documentation | Documentation |
chore |
Maintenance | (usually excluded) |
refactor |
Code refactoring | (usually excluded) |
test |
Test changes | (usually excluded) |
ci |
CI/CD changes | (usually excluded) |
| Tag | Description | Install Command |
|---|---|---|
latest |
Stable releases | npm i -g ralph-starter |
beta |
Beta prereleases | npm i -g ralph-starter@beta |
alpha |
Alpha prereleases | npm i -g ralph-starter@alpha |
- Check that the source PR had the
candidate-releaselabel - Verify the label was added before the PR was merged
- Check GitHub Actions logs for errors
- Verify
NPM_TOKENsecret is set and valid - Check if the version already exists on npm
- Review GitHub Actions logs for specific errors
- If re-releasing the same version, delete the existing tag first:
git tag -d vX.Y.Z git push origin :refs/tags/vX.Y.Z
| Secret | Description |
|---|---|
NPM_TOKEN |
npm automation token for publishing |
GITHUB_TOKEN |
Automatically provided by GitHub Actions |