Versioning & Release Model
Trunk-based development
All repositories follow a trunk-based model:
masteris the trunk. Every push tomasterauto-deploys to the development environment.- Production promotion happens at the epic boundary — a full epic is built and tested on the development environment, then promoted to production once, never story-by-story.
- Work in progress lands on the trunk behind feature flags, so the trunk is always deployable.
Version scheme: CalVer
Deployable services are versioned by calendar date — vYYYY.MM.DD (for example v2026.06.14), with a .N suffix when the same service is promoted more than once on the same day (v2026.06.14.1).
Why CalVer and not SemVer: SemVer's major/minor/patch semantics exist for libraries with consumers who need to know whether an upgrade breaks them. A continuously deployed service has no version consumers — the only question a deploy tag must answer is "what is running, and when did it ship?". A date answers that instantly, removes every "is this a minor or a patch?" debate, and makes incident timelines self-evident. This is how continuously deployed platforms version at scale: date- or build-stamped releases for services, SemVer reserved for published libraries and public APIs.
- Services (
user-management,bot-backend,video-streaming-server): CalVer tags. - Published libraries / public API contracts (if any emerge): SemVer, because those have consumers.
- Tags from before the CalVer adoption (
v0.x,v1.0.x, June 2026) remain valid history and are listed as-is on the sprint pages.
How production promotions work
| Surface | Promotion mechanism |
|---|---|
Backend services (user-management, bot-backend, video-streaming-server) | CalVer tag vYYYY.MM.DD on the trunk triggers the production deploy |
Frontends (interviews-ui, smart-interview-ui) | The production branch pointer is fast-forwarded to the commit being promoted |
Rollback is the mirror image: re-deploy the previous tag (backends) or re-point the production branch (frontends).
How releases are grouped on this site
Releases are grouped by sprint (two-week cadence). Each sprint page lists:
- the sprint window (start and end dates),
- the versions promoted to production during that window, and
- what shipped — completed and QA-passed work items, grouped by type.
Version tagging was introduced with the trunk-based cutover in early June 2026 (Sprint 24); sprints before that shipped through the earlier branch-based pipeline and have no version tags to list.