This document outlines the standardized process for creating releases in the Coffybara project.
- GitHub CLI installed and authenticated (
gh auth login
) - Write access to the
oslabs-beta/capybara
repository - Node.js and npm installed locally
Add a new version section with the changes for this release:
## [0.9.1] - 2025-06-20
### Added
- New feature descriptions
- Enhancement details
### Changed
- Modified functionality descriptions
- Updated dependencies
### Fixed
- Bug fix descriptions
- Security patches
### Removed
- Deprecated features removed
Update all package.json files to the new version:
# From project root
npm version 0.9.1 --no-git-tag-version
# Update client
cd client && npm version 0.9.1 --no-git-tag-version
# Update server
cd ../server && npm version 0.9.1 --no-git-tag-version
# Return to root
cd ..
# Stage all changes
git add .
# Commit with conventional commit format
git commit -m "chore: bump version to 0.9.1
- Updated CHANGELOG.md with release notes
- Bumped package.json versions across all modules"
# Create and push the tag
git tag v0.9.1
git push origin main
git push origin v0.9.1
Once you push the tag, our GitHub Action (.github/workflows/release.yml
) will automatically:
- ✅ Create the GitHub release
- ✅ Extract release notes from CHANGELOG.md
- ✅ Build and attach client artifacts
- ✅ Mark as pre-release (until v1.0.0)
- ✅ Trigger deployment pipeline
If you prefer to create releases manually or the automated workflow fails:
# Using GitHub CLI
gh release create v0.9.1 \
--title "Coffybara v0.9.1 - Bug Fixes & Improvements" \
--notes-file <(awk '/^## \[0.9.1\]/{flag=1; next} /^## \[0.9.0\]/{flag=0} flag' CHANGELOG.md) \
--target main \
--prerelease
Or via GitHub web interface:
- Go to Releases
- Click "Create a new release"
- Tag:
v0.9.1
- Title:
Coffybara v0.9.1 - Bug Fixes & Improvements
- Copy release notes from CHANGELOG.md
- Check "Set as a pre-release" (for versions < 1.0.0)
- Publish release
- 0.x.0 (Minor): New features, API changes, breaking changes allowed
- 0.x.y (Patch): Bug fixes, small improvements, documentation updates
- 0.x.y-alpha.z: Early development, internal testing
- 0.x.y-beta.z: Feature complete, broader testing
- 0.x.y-rc.z: Release candidates, final testing
0.9.0 → 0.9.1 → 0.9.2-rc.1 → 0.9.2 → 1.0.0-rc.1 → 1.0.0
When to use: Bug fixes, security patches, documentation updates
npm version patch --no-git-tag-version
When to use: New features, API additions, significant improvements
npm version minor --no-git-tag-version
When to use: Breaking changes, major API overhauls, stable release
npm version major --no-git-tag-version
Before creating any release, ensure:
- All tests pass locally (
npm test
) - Build succeeds without errors (
npm run build
) - CHANGELOG.md is updated with release notes
- Version numbers match across all package.json files
- Documentation is up to date
- Breaking changes are clearly documented
- Security vulnerabilities are addressed
After creating a release:
- Verify deployment completed successfully
- Test production environment functionality
- Update project boards (Jira/GitHub Projects)
- Notify team members of the new release
- Monitor for issues in the first 24 hours
- Update documentation if needed
For critical bug fixes that need immediate release:
# Create hotfix branch from main
git checkout main
git pull origin main
git checkout -b hotfix/0.9.2
# Make critical fixes
# ... fix the issue ...
# Update version for hotfix
npm version patch --no-git-tag-version
cd client && npm version patch --no-git-tag-version
cd ../server && npm version patch --no-git-tag-version
cd ..
# Update CHANGELOG.md with hotfix notes
# Commit and create PR to main
git add .
git commit -m "hotfix: critical bug fix for v0.9.2"
git push origin hotfix/0.9.2
# After PR merge, create release
git checkout main
git pull origin main
git tag v0.9.2
git push origin v0.9.2
If you encounter issues with the release process:
- Check GitHub Actions for build errors
- Verify the release workflow configuration
- Contact the team leads: Wenjun Song, Steven Yeung, or Amit Haror