Skip to main content

​
Overview

The Trezor Suite monorepo contains multiple projects with different versioning schemes and release schedules:
  • Connect: Public packages following SemVer
  • Suite App: Calendar versioning (CalVer)
  • Private Packages: Fixed at version 1.0.0

​
Versioning

​
Private Packages

Packages with private: true in their package.json that are not published to NPM:
Private packages are consumed by other packages in the monorepo via Yarn’s workspace resolution or distributed as bundled applications.
Examples:
  • @trezor/suite-data
  • @trezor/suite
  • @trezor/suite-desktop
Version: Fixed at 1.0.0 (not incremented)

​
Public Packages

Packages published to NPM and consumed by third parties: Versioning Scheme: Semantic Versioning (SemVer) Format: MAJOR.MINOR.PATCH
  • MAJOR: Breaking changes
  • MINOR: New features (backward compatible)
  • PATCH: Bug fixes (backward compatible)
Examples:
  • @trezor/connect: 10.0.0-alpha.1
  • @trezor/connect-web: 10.0.0-alpha.1
  • blockchain-link: SemVer on irregular schedule
Release Schedule: Irregular, based on feature development

​
Suite App

The Suite application itself uses calendar versioning: Versioning Scheme: Calendar Versioning (CalVer) Format: YY.MM.PATCH
  • YY: Current year (e.g., 20 for 2020)
  • MINOR: Current month (01-12)
  • PATCH: Release number in that month (starts at 1)
Examples:
  • 20.10.1: First release in October 2020
  • 20.10.3: Third release in October 2020
  • 19.12.1: First release in December 2019
Beta versions use a similar format with special rules:Format: YY.MM.0
  • PATCH is always 0 for beta
  • MM is incremented (+1) compared to stable
Example Timeline:
20.10.1  → Oct 15: First stable release
20.10.2  → Oct 22: Second stable release
20.11.0  → Oct 29: Beta for November
20.11.0  → Nov 5:  Another beta deployment
20.11.1  → Nov 14: November stable release
Note: Beta testers should report the commit hash, as the version number doesn’t distinguish between beta deployments.
Development versions follow the beta scheme:Format: YY.MM.0
  • develop branch always has YY.MM.0 for upcoming month
  • When forking to release/20YY-MM, bump to YY.MM.1
  • Increment develop to YY.(MM+1).0 for next release
Example:
develop branch:        20.11.0
↓ fork release branch
release/2020-11:       20.11.1
develop branch:        20.12.0 (next month)
Version Location: Tracked in suiteVersion field of suite package.json Purpose: Communicate evolution of Suite app between product, marketing, support teams and users

​
Environments

​
Staging

URL: staging-suite.trezor.io Access: SatoshiLabs internal IP range only (office + VPN) Purpose:
  • Pre-release testing
  • QA validation
  • Should be 1:1 with production
Deployment: Before public releases

​
Production

URL: suite.trezor.io Access: Public
RouteSourceAssetPrefix
/web@trezor/suite-web/web
Deployment:
  • Stable releases only
  • After successful staging testing
  • Monitored deployment process

​
Connect Deployment

URL: connect.trezor.io Versions:
  • Canary: Latest development builds
  • Stable: Versioned releases
  • Persistent link: connect.trezor.io/10 for latest v10

​
Release Process

​
Suite Release Workflow

1

Development

Features are developed and merged to develop branch:
git checkout develop
git pull origin develop
git checkout -b feature/new-feature
# Develop feature
git commit -m "feat: add new feature"
# Create pull request to develop
2

Create Release Branch

Fork develop to create release branch:
git checkout develop
git pull origin develop
git checkout -b release/2024-03

# Bump version in package.json
# YY.MM.0 → YY.MM.1

git commit -m "chore: bump version to 24.03.1"
git push origin release/2024-03
3

Deploy to Staging

Deploy release branch to staging environment:
  • QA team tests on staging-suite.trezor.io
  • Bug fixes committed to release branch
  • Critical fixes cherry-picked to develop
4

Production Deployment

After QA approval:
# Tag the release
git tag v24.03.1
git push origin v24.03.1

# Deploy to production
# (Automated via CI/CD)
5

Post-Release

Merge release branch back and prepare next release:
# Merge to main/master
git checkout main
git merge release/2024-03

# Update develop for next version
git checkout develop
# Bump to next month: 24.04.0
git commit -m "chore: bump version to 24.04.0"

​
Desktop App Releases

Desktop applications require additional steps:Platform Builds:
  • Windows: .exe installer
  • macOS: .dmg installer
  • Linux: .AppImage
Code Signing:
  • Windows: Sign binaries (see signing-binaries-win.md)
  • macOS: Apple Developer signing
  • Linux: GPG signatures
Auto-Updates:
  • Built-in update mechanism
  • Download and verify updates
  • User-initiated installation
See Desktop Updates for details.
New firmware versions must be bundled:Process:
  1. Firmware released in trezor-firmware repo
  2. Update firmware submodule in Suite
  3. Bundle firmware binaries
  4. Test with Suite
  5. Release Suite update
See Bundling New Firmwares for details.

​
Connect Release Workflow

1

Version Bump

Update version following SemVer:
cd packages/connect
# For major version:
npm version major
# For minor version:
npm version minor
# For patch version:
npm version patch
2

Update Changelog

Document changes in CHANGELOG.md:
# 10.0.0

Features:
- Add Tron support

Breaking Changes:
- Remove EOS support
- Remove NEM support
3

Build and Test

Build all Connect packages:
yarn workspace @trezor/connect build
yarn workspace @trezor/connect-web build
yarn workspace @trezor/connect-webextension build
yarn workspace @trezor/connect-mobile build

# Run tests
yarn workspace @trezor/connect test
4

Publish to NPM

Publish packages to NPM:
# Publish main package
cd packages/connect
npm publish

# Publish platform-specific packages
cd packages/connect-web
npm publish
# ... repeat for other packages
5

Deploy Explorer

Deploy to Connect Explorer:
  • Build Explorer app
  • Deploy to connect.trezor.io
  • Update version links
6

Announce Release

Communicate the release:
  • GitHub release notes
  • NPM release
  • Update documentation
  • Blog post for major versions

​
Release Checklist

  • All features merged to develop
  • Create release branch
  • Bump version (CalVer format)
  • Deploy to staging
  • QA testing completed
  • All critical bugs fixed
  • Deploy to production
  • Create git tag
  • Update documentation
  • Merge back to main/develop
  • Bump develop to next version

​
Version Support

Current Support Policy:
  • Latest major version: Full support
  • Previous major version: Security fixes only
  • Older versions: No support

​
Connect Support

  • Connect 10.x: Active development (current)
  • Connect 9.x: Maintenance mode (security fixes)
  • Connect 8.x and older: Not supported

​
Suite Support

  • Latest release: Full support
  • Previous 2 releases: Bug fixes
  • Older releases: Upgrade recommended

​
Additional Resources

Changelog

See detailed version history

Migration Guide

Upgrade between versions

GitHub Releases

View all releases

NPM Packages

Published packages
For internal release process details, see:

Build docs developers (and LLMs) love

Get started for freeTalk to us