Release Process

Dubby uses a three-channel release process to balance shipping speed with stability.

Release channels

Channel	Source	Docker tag	Cadence	Audience
Dev	Every push to main	:dev	Continuous	Developers, early testers
Beta	Release branch	:beta, :X.Y.0-beta.N	Weekly during beta	Adventurous self-hosters
Stable	Promoted beta	:latest, :X.Y.Z	After 2-week soak	Everyone

Branching model

main ──────────────────────────────────────────── (trunk)
         \
          release/1.2.0 ── beta.1 ── beta.2 ── 1.2.0 (stable)

• main is trunk. All development happens here. Every push builds :dev images automatically.
• Release branches (release/X.Y.0) are created only when cutting a beta. They receive cherry-picked bug fixes only — never new features.
• Feature branches are merged to main via pull request. Never commit directly to main or release branches.

Versioning

Dubby follows Semantic Versioning:

• Major (X.0.0) — Breaking changes to the public API or database schema
• Minor (0.X.0) — New features, non-breaking changes
• Patch (0.0.X) — Bug fixes only

Pre-1.0, breaking changes trigger a minor bump.

Cutting a release

1. Create release branch from main: release/X.Y.0
2. Tag beta: vX.Y.0-beta.1 — builds :beta Docker images
3. Bug fixes: Land fixes on main first, then cherry-pick to the release branch
4. Tag additional betas as fixes land: vX.Y.0-beta.2, etc.
5. Promote to stable after 2-week soak with no critical issues: tag vX.Y.0
6. Patch releases (vX.Y.1) for critical fixes after stable release

Migration freeze

Once a database migration ships in a beta, its SQL is frozen. No modifications allowed — only new migrations on main. This ensures users who upgrade from beta to stable don’t hit migration conflicts.

Hotfix process

For critical security or data-loss bugs:

1. Fix lands on main first (with tests)
2. Cherry-pick the fix to the active release branch
3. Tag a new patch version
4. The fix ships in both :dev and :latest channels

Docker images

Every release publishes four images to Docker Hub:

Image	Description
dubbytv/dubby	Standalone (server + web in one container)
dubbytv/server	API server only (for split deployments)
dubbytv/worker	Background worker only (for split deployments)
dubbytv/web	Nginx web client only (for split deployments)

# Standalone (most users)
docker pull dubbytv/dubby:latest     # Latest stable
docker pull dubbytv/dubby:1.2.0      # Specific version
docker pull dubbytv/dubby:beta       # Beta
docker pull dubbytv/dubby:dev        # Development (latest main)

# Split deployment (Kubernetes)
docker pull dubbytv/server:dev
docker pull dubbytv/worker:dev
docker pull dubbytv/web:dev

Commit conventions

All commits and PR titles follow Conventional Commits. This drives automated changelog generation and version bumping:

Type	Version impact
feat	Minor bump
fix	Patch bump
feat! / fix!	Major bump (minor pre-1.0)
refactor, docs, chore	No version bump