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 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.
Why releases go wrong
Everything a release needs, in one record
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 a release comes together
For teams that ship on a schedule
Which edition includes what
| 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) | ✓ | ✓ | ✗ |
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.