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.

Release Anything (Virtual Versions)

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.

Creating Virtual Versions

To create virtual versions (as any other entity in the App) click on “Create“ button in right top corner.

Open

You can also do it inplace by using approriate link in any column you would like to create it:

Open

Epic

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)

JQL version

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)

Editing Virtual Versions

Click on any Virtual Version to edit it.

Epic

Pick another Epic from look up.

JQL version

Amend JQL if you need to

Changing type of Virtual Versions

If you want to change the type of Virtual Version, just toggle on/off between Epic-based and JQL-based Virtual versions.

Changing scope of Virtual Versions

Packaging Virtual Versions into Releases

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

Use case: SAFe PIs

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.

Use case: Hot Fixes or Service Releases

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.

Rest of functionality

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.

Other limitations

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.