Add multiple releases of a same project into a cross-project release in Portfolio

[nph]

I need to create a cross project release which shall include several releases coming from the same project.

It seems that by default there can be only one release per project: as soon as I have added a release from a project, this project is colored in gray and is not longer for selection when I want to add another release into the cross-project release.

Can you someone help please?

Thanks

Nghia

[Grassmann, Oliver (O.)]

So any statement by Atlassian people here? 

Allowing this is crucial to successfully plan bigger projects! 

Please think about it and please give some feedback, guys! 

Thanks in advance & bests, 
Oliver.

[ZR]

This is a must have. Jira has components, we can create multiple versions, recommendations for component versioning suggest using component-x.y.z, yet we cannot combine those versions using cross-project releases!

[Earl McCutcheon]

Hello @nph ,

The Logic behind the restriction is that a release is a compartmentalized piece of each project, and if you have the ability to combine issues from multiple release within the same project at the same time they should already be lumped together into a single release, and not be separated into alternate sections, the Releases are intended to be Sequentially released mutually exclusive chunks of data.

This is noted in the Cross Project Release documentation in the section "How to add an existing release to a cross-project release" at point "4" stating:

4. Select the release you want to add. Keep in mind that you can only have one release from a project in the cross-project release.

Regards,
Earl

[Neil Hunt]

I have read this logic, but I disagree with it. We have many components (essentially microservices) that are maintained in a single Jira project (essentially a team). Each of those components have their own versions and we track those using Jira Releases individually. For example, I have 

Component A

Component B

I may have the following Releases:
Component A-1.0
Component A-1.1
Component B-3.1
Component B-3.2
Component A-1.2

And I oftentimes want to group one or more of them into a single overall release which I want to use Jira Advanced Roadmaps to track. With the current limitation of only allowing a single release from a project, there is no way to display this in Advanced Roadmaps. I would ask you to please consider adding this feature.

Also, we typically have many components (20+ per Jira project) each with their own versions. To distribute each of those into their own Jira project would be impractical.

[Westlee Latta]

Agreed - Atlassian should allow per-component releases from within the same project. Otherwise why do we have components at all if we're required to have a unique project per release?

[tbertin tbertin]

Hey!

Some years later, and it seems either no one though this would be necessary anymore, or people in need of this feature found another way to achieve what they wanted.

I for one agree with @nph , @Neil Hunt and @Westlee Latta and would very much like to use cross-project releases with several versions included from the same sub-project (owning differents components with each their own specific versions).

It seems the "component" control in Jira is somewhat limited, in a sense that components versions cannot be specified (only project ones) etc... This is not really a problem, but that highlights the limitations in component management inside a single project. For example, having only project-level releases forces users to define versions either comprised of several components (and this becomes difficult to track, as it can only be done by using and reading back the version description), or by creating specific versions for each component inside the project (which is at least better, because a Jira ticket can be assigned several versions in a project, as is possible for a real bug/task/US/whatever).

So, having multiple versions in a project to define one for each component is the best way to handle component versions now, but we currently don't have the possibility to link them all through a cross-project release, which would define a larger release step (for example: defining an end-of-increment or end-of-sprint release comprised of several component upgrades).

I don't know how this limitation is handled internally, but wouldn't its removal have little to no impact on the rest of the product?

@Earl McCutcheon could someone on the Jira team at least consider it?

[Shane Giroux]

Atlassian is choosing again to let the tool tell teams how to work rather than letting the teams tell the tool how they work. In some cases - single assignee on an issue/work item - I can understand (even if there are valid reasons to disagree for some teams).

In others such as this case, it's a restriction that is unwelcome. Planning out a quarterly cross-project release might involve multiple releases from a single project.

Granted this is setup to get around the lack of the larger program management which I understand Program Boards are meant to handle thought hey have their own limitations currently (only two quarters out being a big one so you can't plan a year roadmap)

There is always the chance I - we - are incorrect in how we want to use cross-project releases but I'd need to be convinced the limitation is important to impose and more valuable to have than to not have the restriction.