Release Process

Release Process

Versioning

RocketRide uses lockstep versioning across the monorepo. All packages share the same version number, managed via package.json at the root.

Current version format: MAJOR.MINOR.PATCH (e.g., 1.0.3)

Release Flow

1. Feature work lands on develop via pull requests
2. When ready to release, create a release/x.y.z branch from develop
3. Final testing and bug fixes go on the release branch
4. Merge release branch to main and tag with server-vX.Y.Z
5. Merge main back to develop

Creating a Release

# Create release branch
git checkout develop
git pull origin develop
git checkout -b release/1.1.0

# Bump version
# Update version in root package.json

# Final verification
./builder build
./builder test

# Merge to main
git checkout main
git merge release/1.1.0
git tag server-v1.1.0
git push origin main --tags

# Merge back to develop
git checkout develop
git merge main
git push origin develop

CI/CD

• On PR to develop: Build and test on Ubuntu, Windows, macOS
• On merge to main: Full build, test, and artifact creation
• On tag push (server-v*): Release artifacts published

Artifacts

Each release produces:

Artifact	Location
Engine binary	dist/server/Engine
TypeScript SDK	dist/clients/rocketride-{version}.tgz
Python SDK	dist/clients/rocketride-{version}-py3-none-any.whl
VSCode extension	dist/vscode/rocketride-{version}.vsix

Hotfixes

For critical fixes to a released version:

1. Branch hotfix/description from main
2. Fix, test, commit
3. Merge to main and tag with incremented patch version
4. Merge main back to develop

Changelog

Use conventional commits to auto-generate changelogs:

• feat: entries appear under "Features"
• fix: entries appear under "Bug Fixes"
• BREAKING CHANGE: in commit body flags breaking changes