Releases are at the core of every project; they help teams organize the delivery of their work and act as a historic reference for future needs.

Jira releases are good for managing your releases at a project level. However, difficulties arise when you try to use Jira for release management across multiple projects.

Release hierarchy in Jira

In Jira, you can create many projects, and for each of these projects you can create issues. If you want to track your issues better, Jira offers many options to tag the issues; that includes fix versions (aka releases), components, labels, epics, sprints, custom fields and many more.

  • Releases and components are project-specific and cannot be linked to the issues from different projects.
  • Labels and epics in Jira are global and can be used to tag issues from any project.
  • Sprints are dependent on the board; if you run a board with issues from multiple projects then you can include any of them in the sprint.
Jira releases hierarchy - relationship between Fix versions and Projects
Jira releases hierarchy - relationship between Fix versions and Projects

So where's the problem? This hierarchy is just way too restrictive for cross-functional teams.

When the operation gets bigger teams often decide to split into many smaller projects in Jira. These projects can represent different teams, clients or parts of the operation.

This approach is especially helpful because each team can manage their own tasks, can have different workflows, reports, etc. But when it comes to releases they still need to release only one version that delivers tasks from several of these projects.

How to create cross-project releases in Jira
Share versions between projects in Jira

The solution for having the same Jira release in multiple projects is to create a fix version (aka release) with the same name in all the needed projects. This will enable you to link issues to the needed version. Now we can also JQL by version name to get a list of all issues delivered in this cross-project release.

But here's the thing, these versions aren't connected to one another. If we change anything, from name, to description, release dates or status, we'll need to do it for all for all of the projects manually. And this becomes hard to manage after a while.

Cross-project or portfolio releases aren't part of the core functionality of Jira, but they can be added by using an external app like Swanly.

How to create cross-project releases in Jira using Swanly

In Swanly, you can create a release with multiple projects assigned.

There are 2 ways to create a cross-project release:

  • by creating a new release from scratch,
  • by adding additional projects to the existing release.

Jira versions are then automatically created in each of the selected project and any changes made to any of these versions are then automatically synchronised. Magic! 🎩🐇

You can now assign issues to these versions as usual and instead of updating Jira versions, you can focus on delivering your project.

Share Jira Versions Across Projects in Swanly
Assign multiple projects to the release

Swanly provides much more than just the Jira cross-project releases sync functionality. It showcases your releases in a portfolio release timeline or a list view that you can filter through, and provides advanced release reports on-the-go with:

So you'll find everything you need to know about your releases in one place.

Tracking Progress of Jira Version across Multiple Projects
Track progress of cross-project releases in one place


Yes, free; you can install the app for free if you're 10 users or less, or you can try the demo and see.