A product release or version
A release is a named, versioned bundle of work shipped to users at a point in time. It is the unit at which a product changes hands from the people who build it to the people who use it, and the unit by which everyone else (support, marketing, sales, the users themselves) reasons about what is now true of the product. A release is both a technical artefact and a communication act.
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 dependencyDependencyTeam & 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 flagsFeature 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 changelogChangelogProduct SpecificationA record of changes shipped in a releaseView reference → and the rollout plan now matter as much as the build.
A team prepares release 2.4.0 of a mobile app. The minor bump signals new featuresFeatureProduct SpecificationA product capability or featureView reference → with no breaking changes: a redesigned inbox and push notifications. Before it ships, a milestoneMilestoneProgram 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.
Haines frames the release as a formal deliverable that emerges from a phase-gated lifecycle — concept, feasibility, definition, development, launch — where a gate must be cleared before the product moves forward; the release is the artefact that crosses the final gate. By that framing, the product manager's jobJobUserJob To Be Done: what the user is trying to accomplishView reference → is to own a launch plan that coordinates engineering readiness, marketing timing, sales enablement, and support preparation as parallel tracks, so that "shipped" and "announced" can be timed deliberately rather than conflated.
In the Unified Product Graph, releaseproduct_ships_via_releaseroadmap_schedules_releasemilestone_gates_releaseregression_test_guards_releasereview_gate_blocks_releaselaunch_ships_with_releaselaunch_announces_releasechangelog_documents_release 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.
Worked example: Trellis
The Safe Change general-availability launch is Trellis's anchor release for the current cycle, the version that ships the per-record preview, the plain-language explanation, and one-click rollback as a complete, production-ready featureFeatureProduct SpecificationA product capability or featureView reference →. A release bundles the completed epicEpicProduct SpecificationA large body of work that can be broken into storiesView reference → into a shippable unit and anchors the changelogChangelogProduct SpecificationA record of changes shipped in a releaseView reference → and the roadmap themeRoadmap ThemeProduct SpecificationA customer problem used as the organising unit of a roadmapView reference → it closes.
Type-specific fields on BaseNode
release_datestringScheduled or actual release date (ISO)
versionstringSemver or named version (e.g. "v2.1.0", "Beta 3")
start_datestringISO date work begins
ownerstringResponsible person or team. Promote to a `node_owned_by_person` edge if ownership must be queryable.
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
3 phases, initial: planned
12 edge types connected to this entity.
regression_test_guards_releasereview_gate_blocks_releaselaunch_ships_with_releaselaunch_announces_releasemilestone_gates_releasemilestone_triggers_releasebug_observed_in_release1 framework use this entity type.