We need this for Cloud. I get that it's messy because there's the possibility of a ticket having multiple versions, but please. You're killing us by not making this available. Manually creating swimlanes by query for each fix version is fine if you only have one project; not so great if you have several dozen.

Please

Yes please!

+1

Yes please, to split by versions would be a great feature.

need it as well! 

we could truck the roadmap and development of the project on the board

Upvoting as well. Now that I made versions, swim lanes based on priority mix multiple versions...

voting, need it

I think version is just one of many more ways that one would want to divide up the board into swim lanes.  Why not have them based on the unique values in any issue field?  E.g. maybe I want to divide it up by label (which might be important for particular applications), or by issue type (so I see my defects separate from my stories), or component?  It seems limiting to consider adding version lanes and then the community will turn around and make a separate request for other useful divisions.  You might have to limit the total number of lanes to something (15? 20? 50?) and put the rest in an 'other' lane (in case where someone picks a weird field like comments).  Another consideration is whether you want to see duplicates or not (e.g. if an issue has two components, would you want it shown in both lanes?  Possibly.)  The Structure plugin already has this sort of capability in their 'group by' filter – it's just that the UI is different.

Besides "versions", a lot of users asking also for components. As of today they are using swimlanes based on queries, but it becomes tricky on very dynamic projects.. Would be easier, if users could just select it..

Would be useful for us too!

"Gathering Interest" for 6 years?...  This is incredibly useful functionality for anyone with sprints that span different fix versions (i.e. nearly everyone).  

Would be a great feature. Or even better a way to freely define autmatically extending swimlanes

Is there an update on this ticket?  We would love this function as well.

We would love such function.

I see that this issue has been open for over 6 years and there is a lot of questions and requests for it. Are there any plans to resolve this issue? This would be a big help for my team. Both in Scrum board and Kanban board.

We would love a function like this in order to track our release management a lot better...

This would be a very useful feature for our team

One has to wonder at the logic employed within Atlassian when instead of having "swimlane by X" they are implementing individual requests for "swimlane by epic" or "swimlane by project" - any developer worth their salt would've suggested a more flexible solution.

Talk about making a sow's ear out of a silk purse.

Is there a ticket for this for JIRA cloud?  

This has been an issue since 2012? Why not do it Atlassian? Its just a foreach loop

+1 Swimlanes by Epic are good, by fixVersions would be even better.

+1

We also have users who need to quickly see issues by fixVersion on a board.

+1 Definitely

For us we're managing 20+ Epics in a release and we want to do release planning by moving Epics between versions.  Thus the Epic swimlane isn't really a workaround and custom queries for each version isn't maintainable.

+1

+1 We would use it to quickly sort/see issues on a per Release basis.

+1 to this feature which I am surprised has not been implemented!

My use case is that I have created a Kanban with a very high level view of my projects and would like to have a swimlane per team/project release to track the progress of each,

+1

Would be very helpful to have dynamic swimlanes based on fixVersion

+1 
I did find the 'FixVersion in unreleasedVersions()' option, but it doesn't split the swimlanes out by version. It just displays everything in one, big chunk (by the query name). It's not maintainable/extensible to create a query for every version and doesn't make sense to use epic link for this purpose when there is a version setting to serve that purpose.

Any update on this. Would be great to have swimlanes automatically by all unreleased versions in a project.

+1 Very chore to add versions every time

+1 to this. Currently we have to add a query each time we add a new version

Would be really helpful to have. Swimlanes should be based on any field.

+1. Is there any update on adding this feature?

adding another vote/voice for this.  our workflow is driven by hyper focused versioning.  having an automatic swim lane based on these versions would be much easier to maintain.  as it stands i am creating swim lanes based on queries.  this is fairly tedious to maintain.

+1 this would be very helpful even considering all of the workarounds suggested

 
+1 for this.  So much easier than doing it manually.  We have multiple platforms on the same board (e.g. iOS and Android) that have independent releases.  Having this automatic rather than having to constantly update queries would be extremely useful.

This would be very interesting for us to have as well, preferably on the scrum board - any plans for adding it?

Hi, it would be nice to have this feature.

Hi, is there any news on when this may be available?

Dear Hazze, thank you for pointing out the JQL functions latestReleasedVersion() and earliestUnreleasedVersion(). These are very useful indeed, and I will start thinking if I can alleviate our problem somewhat by using latestReleasedVersion().

For us unfortunately this workaround will not really suit our needs, as we also encode components in our versions, and we therefore really need to see other versions as a swim lane as well.

I had the same problem, but I got it to work like a charm using the guide in this link, see the section Choosing a different type of swimlane:
https://confluence.atlassian.com/agile/jira-agile-user-s-guide/configuring-a-board/configuring-swimlanes

Note that you can only configure the Latest release and the Next release, but it suits our needs anyway.

Also remember to make sure that the FIX versions you have released for your projects really are set as Released in Jira Versions for each project or it won't display your issues as expected.

Any updates on this? This is very important feature on Companies who do multiple projects simultaneously and have teams involved in multiple projects at the same time.

Reading the related ticket you mention, the comments actually relate back to this one and there is a "related" link back to this. I agree that the ticket you reference handles by expansion on the need.

I can also see in the ticket you reference there is a link to a ticket that describes the other suggestion i made in comments related to quick filters (sorry for causing confusion here).

People should be aware of the more general issue, GHS-4669, whose solution would handle this issue as one case. There is no need for a solution for this special case, and this issue should be resolved as a duplicate (or subsumed by) GHS-4669.

If people want changes in quick filters, like the last commentor, they should raise a different issue and not confuse it with swimlane improvements.

yes please!!! or even better simply allow the swim lanes to be defined by any single field. Or alternatively (perhaps even better) enhance the quick filters so that it isnt just a toggle switch but you can have a drop down selection, so i could simply specify the fix version (or component or whatever field) i was interested in filtering by.

I agree with this suggestion, I just received a request to do just this with one of our Kanban boards.

Any updates regarding this feature ?

Many thanks for reporting this issue. We see it as a valid feature request however we cannot provide any guidance at this time as to when, or if, we'll be implementing it.

Regards,
JIRA Agile Team

We are having the same issue. We do it by hand as well and would be happy if this would be part of the funstionality.

This would be really-really good! Especially for kanban teams who deal with release management. Right now we can do this via custom queries, but needs too much administration.

It wouldn't just "be good", for me it's quite necessary. Our team is using the Rapid Board and we're producing software versions. I guess it's some kind of default case to use Swimlanes based on "fix version" for prioritizing. Every time we add or update a "fix version", I need to change the Rapid Board configuration (Swimlanes) manually. It's annoying.

#GHS-4669 instead "would be nice" (really flexible), but to fix this issue (#GHS-5720) is necessary!