For a long time Versions (also called Releases) associated with Versions look up on project level. To assign Jira issues to Versions (Releases) two standard fields are used, namely “Fix version” and “Affects version”. The later is used rarely so it’s all about Fix version” mostly.
This is smth we support natively in the App - fix versions and issues being assigned to it. Sametime, a number of companies are using other ways to define releases - a container of issues. In particular the following approaches are used:
Single- or Multi-select Custom fields with predefined values
Labels
Epic as Release (mainly because Epic could be shared among multiple company-managed projects)
Sprints (when teams are delivering every sprint)
etc.
Let’s come to fix versions for a second.
Practically, what Release is?
Release = all issues where fix version field equals “1.2.3“
So, basically it’s JQL.
This became a notion of what we call Virtual Versions.
At the moment we support the following types of Virtual Versions:
Epics
pure JQL version
Why do we need to differentiate?
Similar to fix versions, epics are defined via specific standard/custom fields therefore we can add/remove Jira issues from Epic-based versions, we can track when items were added/removed from the versions .. thus we can have more possibilities of managing and generating insights. Pure JQL version is just a container of issues gathered by certain criteria.
To create virtual versions (as any other entity in the App) click on “Create“ button in right top corner.
You can also do it inplace by using approriate link in any column you would like to create it:
If you click “Add Epic” from Create menu item or inplace adding items to the board the dialog will show up where you can:
Select multiple Epics you would like to add to the board (we will pull all the Epics from the projects you specified while creating the board to populate the lookup)
Shedule them on roadmap/calendar via specifying Start/Release Date
Include them into Release in bulk (if applicable)
If you click “Creqate JQL version” from Create menu item or inplace adding items to the board the dialog will show up where you can:
Specify valid JQL for your Virtual Version
Define Name, Description
Shedule it on roadmap/calendar via specifying Start/Release Date
Include it into Release in bulk (if applicable)
Click on any Virtual Version to edit it.
Pick another Epic from look up.
Amend JQL if you need to
If you want to change the type of Virtual Version, just toggle on/off between Epic-based and JQL-based Virtual versions.
You can’t change scope only for Epic-based and JQL-based virtual versions. |
Virtual versions could be packaged in cross-project releass as any other fix version.
Once you click on your release you can specify what Epics or JQL versions you would like to add
If you practice SAFe you might create Release as PI to include
specific versions of software components you plan to deliver in scope of this PI
sequence of Sprints via JQL based versions
product Epics representing major functionality that will be delivered
Hot Fixes or Service Release you had to work on during PI.
Let’s say you delivered version 1.2 of your Payment Gateway. Shortly after you realized you need to do a Hot Fix or Service Release to repair some integrations broken by the latest changes.
The recommended approach is yet another fix version with appropriate scope. But some teams are trying to avoid it as this multiplies the number of fix versions that will be used.
Instead you can create a JQL version with
fixversion = “1.2“ and labels equal “HF 1.2.3”
You can also package it with fix version into release so you have ultimate visibility on the core version and all Hot Fixes or Service Releases produced.
When it comes to the rest of functionality virtual versions are equal to fix versions in all the use cases.
There are some minor limitations though.
It’s a bit of a technology challenge to calculate Burnup/Trends for Epics/JQL-versions therefore as of today this functionality is not available.