--- title: "Release and Version Management Software | Orangescrum" description: "Plan versions, roll up work into releases, approve them, and publish release notes automatically. Includes a release calendar and blackout windows." canonical: https://www.orangescrum.com/release-management --- # Release and Version Management Software | Orangescrum > For the complete documentation index, see [llms.txt](https://www.orangescrum.com/llms.txt). [Home](/) / [Features](/features) / Release Management Release Management # Release and Version Management, _End to End_ Define a version, roll up everything going into it, get it approved, and publish the release notes automatically. Track dependencies and protect your blackout windows. Available inCloud[Self-Hosted](/self-hosted "Self-Hosted - included")Open Source [Explore Self-Hosted →](/self-hosted)[Book a Demo](https://calendly.com/orangescrum) Available in the Self-Hosted edition - runs on your own servers This capability is available in the **Self-Hosted (on-premise)** edition. It is not part of the Cloud edition today. ## What is release management? Release management is how a team decides what goes into a version, checks it is ready, approves it, and ships it. Orangescrum gives each version its own record, rolls up the tasks and defects included in it, runs the approvals you require, and generates the release notes from the work itself, so what you tell people matches what actually shipped. The problem ## Why releases _go wrong_ Nobody agrees what is in the release The scope lives in a chat thread and changes on the day of the release. ✓ A version record that rolls up every task and defect included. Release notes are written from memory Someone writes them the night before and misses half the changes. ✓ Notes generated automatically from the work in the release. Releases land at the worst time A release ships during a freeze period or a critical business window. ✓ Blackout windows and a shared release calendar stop that happening. What you get ## Everything a release needs, _in one record_ Grouped the way a release is run: the version, the release itself, who approves it, the rules it obeys, what you publish, and what you learn afterwards. 01Versions - ### A version record with a goal Each version carries a name, a key, a description, a goal, an owner, and planned start and end dates. - ### Six lifecycle states Draft, planned, active, on hold, released, and archived, with only sensible moves allowed between them. - ### Roll up five kinds of work Attach epics, features, stories, tasks, and defects to a version and see the whole scope in one list. - ### Progress from the items themselves Completion is calculated from the work attached to the version rather than typed in by somebody. - ### A weekly item chart See how many items moved into the version each week, so scope creep is visible. - ### A roadmap across projects Versions and releases are laid out as lanes per project, so you can see the shape of the year. - ### Archive one when it is done A released version is archived and stays readable, with its scope and history intact. 02Releases - ### Several releases inside one version A version can ship in more than one release, each with its own number and its own date. - ### Six release types Major, minor, patch, hotfix, beta, and release candidate, each with its own readiness bar. - ### Eight lifecycle states Draft, planned, testing, ready, approved, released, rolled back, and cancelled. - ### Ship only part of the version Pick a subset of the version's items into a release, so a hotfix is not the whole version. - ### A readiness check before it moves on A release cannot reach ready until enough of its work is done, at a threshold set by the release type. - ### A shared release calendar Everyone can see what is planned to land and when, in one calendar rather than several. - ### A release dashboard One screen for the state of every release, with the open work still sitting behind each one. - ### Record a rollback If a release has to be pulled, that is a state on the record rather than a message in a chat. 03Approvals - ### Define an approval chain once Build an ordered set of approval levels and reuse it, company wide or for a single project. - ### A person, a role, or a fallback Each level names a person or a role, and falls back to an owner or admin if nobody matches. - ### Levels run in order Level two cannot act until level one has approved, so sign off cannot be jumped. - ### A rejection stops the chain One rejection ends the whole approval, with the comment kept on the record for later. - ### An electronic signature record When an approver confirms, the time, the address, and the browser are recorded next to the decision. - ### Your own pending queue Approvers get one list of everything waiting on them, across every project. - ### Chasing when one is overdue An approval sitting too long triggers a reminder to whoever is holding it up. 04Governance - ### Edit the transition matrix Decide which status may follow which, in a grid where terminal states are marked. - ### Seven workflow presets Three ready made version workflows and four release workflows, from simple to strictly gated. - ### Override a workflow for one project A single project can run a different workflow without changing anybody else's. - ### Conditions on a move Demand that all items are resolved, that notes exist, that approvals exist, that a date is set, or that a minimum number of items are attached. - ### Blackout windows Block releases during a freeze or a peak period, scoped by project and release type, repeating yearly if you need. - ### Release dependencies Record that one release blocks another, refuse a circular chain, and stop a release shipping while a hard dependency is open. - ### A release checklist Attach the steps a release must go through, mark some as required, and tick them off as you go. - ### Permissions per role Version, release, approval, notes, dependency, blackout, retrospective, and administration rights are all separate. - ### Retention and threshold settings Set change log retention, archived version retention, the defect leakage window, and how long an approval may sit before it counts as overdue. 05Release notes - ### Generated from the work included The notes are built from the items attached to the release, so nobody has to remember what shipped. - ### Grouped the way readers expect Epics and features become new features, stories and tasks become improvements, and defects become fixed issues. - ### Edit them by hand Override the generated text when you need to, and regenerating asks first so your edit is never lost silently. 06Retrospectives - ### Reusable retro templates Define the sections a retro should cover once and use them for every release afterwards. - ### One retro per release Each release has exactly one retrospective, so there is never a question about which one is current. - ### Required sections before publishing A retro cannot be published until the sections you marked as required have been filled in. - ### Add an addendum afterwards Something learned later can be added without rewriting what was already published. - ### Action items across releases Pull every action item from every retro into one report, so they do not quietly disappear. 07Collaboration - ### Threaded comments with mentions Discuss a version or a release on the record, and mention a colleague to pull them into it. - ### Watch a version or a release Follow the ones you care about and be told when they move, without asking anybody. - ### Choose what you are emailed about Each person sets their own preference per event rather than being sent everything. - ### Six notification events Approval requested, approval overdue, status changed, date approaching, notes overridden, and comment posted. - ### Edit the emails themselves Change the subject and body of each notification, with a token reference, and reset one back to default. 08Analytics - ### Time spent in each status See where a release actually sat, so you know which stage is the slow one. - ### Approval cycle time Median and ninetieth percentile time to approve, broken down by level and by approver. - ### Planned against actual dates How far your release dates slip, by release type and by quarter. - ### Defect leakage How many defects turned up after a release went out, over a window you set yourself. - ### Release velocity How many releases shipped each quarter, and of which type. - ### A failure trend Rolled back, cancelled, and slipped releases counted per month, so a bad run is visible early. - ### An append only change log Every change is written to a log that is never edited or deleted, and shown as a timeline on the record. - ### Customer impact segments Define the customer segments you serve and mark which items in a version affect which of them. - ### A customer impact report you can export Filter by segment and date range and take the result away as a spreadsheet file. How it works ## How a release _comes together_ 1 Define the version Create the version and set its goal, owner, and target dates. 2 Roll up the work Epics, stories, tasks, and defects are attached to the version as they are completed. 3 Approve The readiness check runs, approvers sign off in order, and blackout windows stop anything shipping at the wrong time. 4 Publish and review Release notes are generated from the work included, and the retrospective captures what to change next time. Who it's for ## For teams that _ship on a schedule_ Software and product teams Teams running regular releases who need scope, approval, and notes handled properly. [Learn more →](/solutions/it-project-management-software) Regulated delivery Organisations that must show a release was reviewed and approved before it shipped. [Learn more →](/self-hosted) Multi team programs Programs coordinating dependent releases across several teams. [Learn more →](/program-management-software) Availability ## Which edition includes _what_ Orangescrum runs as managed cloud, self-hosted on your own servers, or as the open-source Community Edition. Here is exactly what each one includes. Release Management is part of the Self-Hosted edition. | Capability | CloudManaged SaaS | Self-HostedOn-premise / private cloud | Open SourceCommunity Edition | | Version records with goal, owner, and dates | ✗ | ✓ | ✗ | | Six version states and eight release states | ✗ | ✓ | ✗ | | Roll up epics, features, stories, tasks, and defects | ✗ | ✓ | ✗ | | Progress and weekly item charts | ✗ | ✓ | ✗ | | Roadmap and release calendar | ✗ | ✓ | ✗ | | Several releases inside one version | ✗ | ✓ | ✗ | | Readiness thresholds by release type | ✗ | ✓ | ✗ | | Multi level approval chains | ✗ | ✓ | ✗ | | Electronic signature on an approval | ✗ | ✓ | ✗ | | Editable transition matrix with seven presets | ✗ | ✓ | ✗ | | Per project workflow overrides | ✗ | ✓ | ✗ | | Blackout windows | ✗ | ✓ | ✗ | | Release dependencies with circular checks | ✗ | ✓ | ✗ | | Release checklists | ✗ | ✓ | ✗ | | Generated release notes with manual override | ✗ | ✓ | ✗ | | Retrospectives, templates, and action item report | ✗ | ✓ | ✗ | | Comments, mentions, and watchers | ✗ | ✓ | ✗ | | Email notifications with editable templates | ✗ | ✓ | ✗ | | Cycle time, predictability, leakage, and velocity | ✗ | ✓ | ✗ | | Append only change log | ✗ | ✓ | ✗ | | Customer impact segments and report | ✗ | ✓ | ✗ | | Sprints and milestones (delivery planning, not release control) | ✓ | ✓ | ✗ | Frequently asked questions ## Release Management _FAQ_ ### What is Orangescrum Release Management? It is a module for planning and controlling versions. You define a version, roll up the work going into it, approve it, and publish release notes generated from that work. It also gives you a release calendar, dependency tracking, blackout windows, and a retrospective on every release. ### Which edition includes Release Management? Release Management is available in the Orangescrum Self-Hosted edition. It is not part of the Cloud edition today. ### How are release notes generated? They are built from the epics, features, stories, tasks, and defects attached to the release, grouped into new features, improvements, and fixed issues. You can override the text by hand, and regenerating asks first so your edit is not lost. ### What is a blackout window? A blackout window is a period when releases are not allowed, such as a code freeze, a financial close, or a peak business period. You can scope it to certain projects and release types, and repeat it yearly. ### Can we require approval before a release? Yes. Approval chains run level by level, each level names a person or a role, one rejection stops the whole chain, and the approver's confirmation is recorded with the time and address. ### Does it handle dependencies between releases? Yes. You can record that one release blocks another. Circular chains are refused, and a release with an open hard dependency cannot ship. ### Is this the same as sprints and milestones? No. Sprints and milestones plan delivery work and are available in Cloud and Self-Hosted. Release Management controls the version itself, including readiness, approval, notes, calendar, and blackout rules. ### What can we learn from past releases? Analytics cover time spent in each status, approval cycle time, planned against actual dates, defect leakage after a release, release velocity by quarter, and a trend of rolled back or slipped releases. ## Ship releases with confidence Release Management is included in the Orangescrum Self-Hosted edition, running entirely on your own infrastructure. [Explore Self-Hosted →](/self-hosted)[Book a Demo](https://calendly.com/orangescrum) ## Related capabilities [Self-Hosted editionRun Orangescrum on your own servers](/self-hosted)[Test Case ManagementProve quality before you ship](/test-case-management)[Bug and issue trackingTrack defects into a release](/bug-and-issue-tracking)[Document ManagementApprove release documentation](/document-management)