Plan what ships and prove it was ready. Create versions, attach the work items that belong to them, and roll them up into releases with their own lifecycle. Readiness is computed from the attached items rather than asserted, approvals run as a sequential chain with delegation, blackout windows stop a release landing during a freeze, dependencies stop one landing before another, release notes are generated from the work itself, and a retrospective closes the loop.
- Installs
- Available
- Support
- Vendor Supported
- Trust
- Self-Hosted
Active deployments
Priority response
Your infra, your data
Screenshots
Key Features
Versions and Releases
A version collects the work planned for it. A release is what actually ships, and can span versions. Both are records with their own lifecycle rather than a label typed into a field.
Work Item Association
Attach epics, features, stories, tasks, and defects to a version or a release. Scope becomes a query rather than a spreadsheet somebody maintains on the side.
Computed Readiness
Readiness is calculated from the state of the attached items against completion thresholds for the release type, so it reflects the work rather than an optimistic status field.
Approval Chains
Sequential multi-level approval on a release, with delegation when an approver is away and a scheduled check that flags steps which have gone overdue.
Blackout Windows
Declare the freeze periods when nothing may ship, with a recorded override when something genuinely must. The window is enforced rather than remembered.
Release Dependencies
Say that one release must land before another and have that order enforced, so the ordering constraint lives in the tool rather than in one architect's head.
Generated Release Notes
Notes are generated from the attached work items and sorted into new features, improvements, fixed issues, and known issues. Edit the result, or regenerate it when scope moves.
Templates and Checklists
Save a release template with its checklist so every release of a given kind starts from the same set of steps instead of from whatever the last person remembered.
Progress, Burndown, and Velocity
Per-version progress, a burndown, and velocity, plus a roadmap view across versions, so a slipping release is visible while there is still time to act on it.
Release Calendar and Dashboard
See what is landing when, with a dashboard for the current picture and a failure trend for the pattern behind the individual incidents.
Customer Impact
Define customer segments, associate them with releases, and produce an impact report, so the question of who is affected has an answer before the change goes out.
Retrospectives
Run a retro against a template with sections, publish the outcome, add addenda later, and promote an action item into real tracked work rather than leaving it in a document.
Comments, Mentions, and Watchers
Discuss a version or a release in place, mention the person who needs to see it, and watch anything you cannot afford to miss, with your own notification preferences.
Change Log and Workflow Rules
Every change is recorded, and status transitions can carry conditions, so the lifecycle is something the tool enforces rather than something a runbook describes.
Webhooks and Email Templates
Send release events to your own systems, and edit the wording of the notifications your organisation sends, without changing code.
Permissions Down to the Action
More than thirty keys grouped by version, release, approval, notes, audit, collaboration, templates, webhooks, dependencies, blackout windows, retrospectives, customer impact, and administration.
About this plugin
Why the plugin page and the feature page both exist
There is a fuller marketing walk-through of release and version management at /release-management, covering what the module is for and how teams use it. This page is the self-hosted add-on entry: what is in the package, what it needs to run, how it installs, and where its edges are. Read the feature page first if you are deciding whether you want this at all, and read this one when you are deciding how to deploy it.
Readiness that is computed, not claimed
A release's readiness comes from the state of the work items attached to it, measured against completion thresholds for the release type. That is a deliberately different thing from a status field somebody sets. It means the readiness signal disagrees with the optimist in the room when the work says it should, which is the entire point of having one.
Gates that hold
Three separate things can stop a release landing: an approval step that has not been given, a blackout window covering the date, and a dependency on another release that has not shipped. Each is enforced rather than documented. Blackout overrides are recorded, so an exception is a decision with a name on it rather than an unnoticed exception.
Notes written from the work
Release notes are generated from the items attached to the release, sorted into new features, improvements, fixed issues, and known issues. The draft is editable and can be regenerated when scope changes late, which it will. Nobody has to reconstruct a changelog from a commit history at five o'clock on release day.
Closing the loop
Retrospectives run against templates with defined sections, get published, can take addenda when something surfaces later, and produce action items that promote into real tracked work. That last step is what stops a retro being a document that gets written once and never opened again.
Who is affected
Customer impact segments let you say which parts of your customer base a release touches, and produce a report from it. For teams who have to tell an account manager or a regulator what changed for whom, that is the difference between an answer and an afternoon of archaeology.
What's included
- Versions with create, edit, archive, and lifecycle transitions
- Releases with create, edit, ship, and rollback
- Association of epics, features, stories, tasks, and defects to versions and releases
- Readiness computation from attached items against per-release-type thresholds
- Sequential multi-level approval chains on releases
- Approval delegation when an approver is unavailable
- Scheduled checks for overdue approvals and approaching dates
- Blackout windows with recorded overrides
- Release dependencies with order enforcement
- Release notes generated from work items into new features, improvements, fixed issues, and known issues
- Editable and regenerable release notes
- Release templates with reusable checklists
- Release checklists tracked per release
- Per-version progress, burndown, and velocity charts
- Roadmap view across versions
- Release calendar, dashboard, and failure trend
- Customer impact segments, associations, and an impact report
- Retrospectives with templates, sections, responses, addenda, and publication
- Retro action items that promote into tracked work
- Comments with mentions on versions and releases
- Watchers with per-person notification preferences
- Configurable workflow transitions with conditions
- A change log covering every recorded change
- Outbound webhooks for release events
- Editable email templates, registered with the email templating module
- Bulk operations across versions and releases
- More than thirty permission keys across fourteen groups
- A health endpoint for monitoring
- Multi-tenant company-scoped data isolation
Compatibility
Requires the Orangescrum Self-Hosted edition running PHP 8.2+, CakePHP 4.6+, and PostgreSQL 16. The plugin folder is VersionRelease and it is gated by the VERSION_RELEASE_ENABLED flag in config/constants.php. The interface is a Vue single page application served from the plugin. Two scheduled commands should be run from cron: one for overdue approvals and one for approaching dates, without which those alerts are never raised. Editable email templates require the email templating module to be loaded; the add-on registers its templates with it at bootstrap and works without it, just without the editing screen. Multi-tenant aware, so every version, release, approval, window, dependency, note, and retro is company-scoped.
Installation
A self-hosted install takes a few minutes. Buy the add-on, drop the plugin into your plugins/ directory, run the migrations, and you're live.
- 1
Buy the add-on
Purchase the Release Management add-on from /self-hosted/pricing. Pricing for this add-on is being finalised, so confirm the current figure with sales before you budget.
- 2
Drop the plugin into your install
Copy the VersionRelease/ folder into plugins/ on your self-hosted Orangescrum server and register `VersionRelease` in src/Application.php with `routes => true, bootstrap => true`.
- 3
Enable the feature flag
Confirm `define('VERSION_RELEASE_ENABLED', true);` in config/constants.php.
- 4
Run the database migrations
Run `bin/cake migrations migrate --plugin VersionRelease` to create the version, release, item, approval, notes, template, checklist, dependency, blackout, impact, retro, workflow, and webhook tables.
- 5
Seed the permission matrix
Run `bin/cake migrations seed --plugin VersionRelease --seed VersionReleaseRbacSeeder` to register the module, menu entry, and role defaults. It is safe to run more than once.
- 6
Schedule the two check commands
Add cron entries for the overdue approval check and the approaching date check. Neither is driven by page traffic, so without a schedule those alerts never fire.
- 7
Configure your lifecycle and gates
Set the workflow transitions and any conditions on them, declare your blackout windows, create the release templates and checklists your teams should start from, and define your customer impact segments.
- 8
Run one release end to end
Create a version, attach its work items, roll it into a release, walk the approval chain, generate the release notes, ship it, and run the retro. One full pass surfaces any policy gap before it matters.
Frequently Asked Questions
What is the difference between a version and a release?
▾
A version collects the work planned under a number, which is how a product team usually thinks. A release is the event of shipping, which is how a delivery or operations team usually thinks, and it can span more than one version. Keeping them separate means the planning conversation and the go-live conversation do not have to use the same record.
How is readiness calculated?
▾
From the state of the work items attached to the release, measured against completion thresholds that vary by release type. It is computed on read and never written, so it cannot be set by hand to make a dashboard look better. If the attached work is not done, the readiness signal says so.
What actually stops a release from shipping?
▾
Three things, each enforced rather than advisory: an approval step that has not been given, a blackout window covering the intended date, and a dependency on another release that has not shipped yet. Blackout windows can be overridden when there is a real emergency, and the override is recorded against the person who made it.
Where do release notes come from?
▾
From the work items attached to the release. They are sorted into new features, improvements, fixed issues, and known issues based on the item type and state. The generated draft is editable, and it can be regenerated when scope changes, which means late scope movement is a button rather than a rewrite.
Does it deploy anything?
▾
No. This is the planning, governance, and record-keeping layer. It does not build artefacts, run pipelines, push to environments, or roll code back. Marking a release as rolled back records that decision in Orangescrum; the actual rollback happens in whatever deployment tooling you already run.
Do the overdue and approaching-date alerts need anything set up?
▾
Yes. Two console commands raise them, one for approvals that have gone past their expected date and one for dates approaching. They are not triggered by page traffic, so if they are not on a schedule those alerts simply never fire. Put both on cron as part of the install.
How granular are the permissions?
▾
More than thirty keys across fourteen groups: version, release, approval, notes, audit, collaboration, templates, webhooks, email, dependencies, blackout windows, retrospectives, customer impact, and administration. Acting on an assigned approval step, delegating one, and administering the module are separate keys, which is what lets you give approvers what they need and nothing else.
Ready to deploy Release Management on your own infrastructure?
Talk to our team about Orangescrum Self-Hosted Enterprise: your data, your servers, full control.