Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Multiple releases assign to a specitif issue Edited

Hi, I'm using Advance Roadmap and cross projects releases. 

Advance Roadmap doesn't allow the allocation of two releases on a single issue so I can't assign the cross-project releases to issues which already have a projet release. 

anyone can confirm this behaviour and suggest any workaround ? Thank you !!

2 answers

1 accepted

NOTE: Half of what I wrote here is WRONG. See remainder of the thread below.

The short answer is: that's just how Jira works.

The "Fix Version" field (aka Release or Version) is not a multi-select field, it can only contain a single value. That field (and only that field) is what Jira uses for Advanced Roadmap releases, and for the Releases (Versions) portion of Jira projects.

The general concept is that an issue, once fixed (done), will be in a release and deployed. Deploying the same fix or feature multiple times (e.g. in several releases) doesn't achieve anything.

I'm guessing that your use-case is that different parts of the business (e.g. different teams or groups) have their own Releases, but yet might rely on the same work to be completed. To my understanding, Jira doesn't directly support that one-issue-to-many-releases model.

One of the strengths of Jira's approach is that, for any given Release, you can get a definitive list of everything that was included. This is great for things like release notes, figuring out if/when thing X actually was released, etc.

As for workarounds -- if your overlapping releases are hierarchical, then using Themes or Initiatives as layers above Epics might be useful for you. More here. But I suspect that's not what you really want.

In Jira, the "Fix version" field is a multi-select field (see example with 5 fix versions) 2021-05-04_15h20_20.png

Anyway, your answer is very helpful and helped me understand my approach was not good 

Wow, you're right. Bad assumption on my part. I would have liked to add strikeout to the stuff I got wrong in my original answer. I added a NOTE instead.

Hint: the "Fix Versions" field is plural for a reason.  :-/

Some further testing shows that Advanced Roadmaps only seems to show an issue under one of the Releases that is included in the Fix Versions field. Changing the order of Releases in the Fix Versions field didn't seem to matter. Not sure how Advanced Roadmaps decides which release to put an issue in.

Due to that non-determinism, it seems like Advanced Roadmaps simply does not support multiple Fix Versions well. It would be too weird, really, to have one issue appearing in multiple places in a Roadmap when grouping the display by Release, for example.

What I've seen in practice in Jira (without Advanced Roadmaps) is that an Epic is used group a larger effort that can span multiple releases, and the Story-level issues in that Epic are assigned the appropriate FixVersion for when they are released. This helps a team focus on burndown to a specific release, for example, while staying in the context of the larger Epic. And the Epic burndown helps track that wider effort.

0 votes
Dave Atlassian Team May 04, 2021

Hi @BrosseauDamien _Consultant_,

The reason that Advanced Roadmaps doesn't allow you to assign multiple releases to an issue is to the impact this would have on the scheduling algorithm ("Auto-Schedule" in the new interface but previously known as "Calculate" in the older Live Plans interface).

If an issue is assigned to more than one release then it presents a challenge to know how to schedule that issue. Although a simple answer might be that you just take the earliest release, it's possible that you can have multiple releases with no fixed start or end dates.

Whilst this is not an insurmountable problem to solve it has never been a high enough priority (and demand not great enough) for it to be addressed. In the previous Live Plans interface it was only possible to generate a roadmap via the scheduling algorithm, but in the new interface it is possible to manually create one so there is considerably less reliance on it. 

I appreciate that this isn't solving your problem but I thought it might be helpful to provide some context on why the limitation exists.



It seems like the auto-scheduler algorithm could assume that an issue with multiple releases should be scheduled to be completed for any of the releases.

But the single-release behavior is baked in now, and as noted, it's unlikely to change.

For those wanting to vote up this feature:

Suggest an answer

Log in or Sign up to answer
Community showcase

The benefits of using Jira in different departments

Jira is a great tool to use across different departments. Forget that paperwork – switch to Jira and get that tasks done smoothly. Marketing Jira allows for a complete digital transformation of you...

103 views 0 6
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you