LEARN. PRACTICE. GROW.Concept and mechanism
A Release Manager coordinates an identified set of changes toward a usable outcome, connecting product, development, testing, change, and operations. The mandate varies across organizations, so decisions and boundaries should be explicit. A repository release can gather a version, notes, and artifacts for distribution; publishing it does not establish production installation or business acceptance. Deployment places a version in an environment, while activation can expose a capability to users at another time. Define package scope and which stages need their own evidence. A task-completion percentage does not replace understanding which version is actually available and to whom.
Guided application
In a fictional example, a new API is installed, but the capability remains disabled behind a feature flag. Reporting should distinguish completed deployment from pending activation and identify who may decide exposure. Confirm consumer compatibility, validation criteria, and support conditions. If a last-minute request adds a change to the package, do not assume earlier evidence remains sufficient. Assess differences, dependencies, and authority to change scope. Maintain an understandable list of included items, deferred items, and the expected outcome. A well-coordinated release allows decisions to be reconstructed without depending on one participant’s memory.
Published, installed, and activated are states that can occur at different times.
Common pitfalls
Publication treated as production; deployment treated as activation; scope added without review; completion by ticket count.
Related topics: Artifacts, integrity, and evidence · Sequence, capacity, and dependencies · Readiness and gradual exposure
Report the version, state, and outcome actually established by evidence.
Reference: About releases · Google SRE release and canary guidance; GitHub immutable releases and GitLab release evidence and deployment safety; DORA five-metric model; inspected 2026-10-01