Release

Origin & evolution

Software has versioned its shipments since the earliest commercial distribution, but the practice was informal for decades; version numbers meant whatever each vendor decided they meant. The discipline that turned a release number into a contract is Semantic Versioning, proposed by Tom Preston-Werner (co-founder of GitHub) in 2010. SemVer fixed a MAJOR.MINOR.PATCH scheme where a patch bump means backward-compatible fixes, a minor bump means backward-compatible additions, and a major bump signals breaking changes. That made a version number machine-readable, which is what made automated dependency⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → management possible.

Release cadence evolved alongside it. Continuous delivery, set out in Jez Humble and David Farley's Continuous Delivery (2010), pushed teams from large, infrequent releases toward small, frequent, automated ones, on the argument that small batches fail less catastrophically and are easier to diagnose. The release stopped being a heavyweight event and became something a team might do many times a day.

Two refinements separated "shipped" from "exposed". Feature flags🎌Feature FlagEngineeringA feature toggle for controlled rolloutView reference → let code release to production while staying dark until toggled on, and progressive rollout (canary and percentage-based releases) let a release reach 1 percent of users before 100 percent. The modern release is therefore a spectrum of exposure, not a single switch, which is why the changelog🕰️ChangelogProduct SpecificationA record of changes shipped in a releaseView reference → and the rollout plan now matter as much as the build.

How it works in practice

A team prepares release 2.4.0 of a mobile app. The minor bump signals new features⭐FeatureProduct SpecificationA product capability or featureView reference → with no breaking changes: a redesigned inbox and push notifications. Before it ships, a milestone⛳MilestoneProgram ManagementA key date or achievementView reference → gates it, holding the release until a regression suite passes and a review sign-off clears. The release then rolls out to 5 percent of devices for 48 hours. Crash-free sessions hold at 99.8 percent, so it widens to 100 percent.

A changelog documents what changed, in user language, and the marketing launch is timed to the 100 percent point rather than the build date. When a crash spikes a week later, the team knows the exact release boundary it appeared in, which narrows the search to the diff between 2.3.x and 2.4.0. The release has done double duty: it is the thing shipped and the coordinate everyone uses to locate cause.

Release vs. its neighbours

• Milestone is a scheduling checkpoint that a release must clear, such as "feature-complete" or "code freeze". The milestone gates the release; the release is the shipment that passes through the gate.
• Changelog is the human-readable record of what a release contained. The release is the bundle; the changelog is its public account. One documents the other.
• Launch is the go-to-market event around a release: the announcement, the campaign, the timing. A release can ship silently with no launch, and a launch can be planned around a release that already shipped. They coincide often and are not the same act.

In the graph

In the Unified Product Graph, release🚢ReleaseProduct SpecificationA shipped version of the product is a container in the Product and Delivery region, attached to the product by product_ships_via_releaseProductships viaReleasehierarchy and scheduled by roadmap_schedules_releaseRoadmapschedulesReleasehierarchy. Its gating and quality relationships are explicit: milestone_gates_releaseMilestonegatesReleasecross-domain, regression_test_guards_releaseRegression TestguardsReleasecross-domain, and review_gate_blocks_releaseReview GateblocksReleasecross-domain each model a different way a release can be held back. The go-to-market side connects through launch_ships_with_releaseLaunchships withReleasecross-domain and launch_announces_releaseLaunchannouncesReleasecross-domain, while changelog_documents_releaseChangelogdocumentsReleasecross-domain ties the shipment to its record. Holding those edges separately is what lets the graph answer "what shipped, when, gated by what, announced how", which is precisely the question a release is supposed to make answerable.