Release Management Best Practices

Overview

A Release is a titled, versioned Change Set that is coordinated and moved, in a governed and sequenced manner, across one or more IT Operating Environments toward its intended target Environment. A Version is the Asset’s current, at-rest operating state once a Release lands at its target Environment — carrying the full Release ID, including its Iteration digit (e.g., “Version 1.1.6,” not truncated to “Version 1.1”).

Release and Version are not two different numbering systems — they are the same identifier, named differently depending on where it sits: “Release” while it is still in motion, being coordinated and validated across Environments; “Version” once it is live and stable at its target Environment. Both terms refer to the same governed Change Set.

This distinction matters practically because a Release can still fail, be rejected, or be rolled back — but a Version, once live, is what stakeholders are actually using and what Change Management, Incident Management, and support are anchored to. Within a Release Lifecycle, only the Iteration that ultimately succeeds becomes a Version. For example, if Product X’s target Release 1.1 requires six Iterations (R1.1.1 through R1.1.6) before succeeding, only R1.1.6 ever becomes a Version; R1.1.1 through R1.1.5 never do, since they were rejected before reaching the target Environment.

This also clarifies what a Rollback reverts to: rolling back Version 1.1.6 reverts to whatever the previous successfully-reached Version was (e.g., “Version 1.0.4”) — never to a failed Iteration like 1.1.5, since a failed Iteration never became a Version in the first place.

A related question worth answering directly: is an Emergency/Hotfix Release a new Release or a new Version? It is a Release — specifically, the Emergency/Hotfix Release Type — and it only becomes a Version once it succeeds and reaches its target Environment, exactly like any other Release Type.