How many values can a field have?

[Andreas Lorz]

Hi,

we want to know how many values are possible for an standard single-choice drop down field?

Why we want to know this?

We have something like 'planned' company releases. To assign a requirement to a certain release we want to use a new field. We have like 50 releases each year. And of course, the total amount of values will grow each year by this nummber. 

We think about this solution because the fix Version is not a cross-project version.

We can't syncronise the fix Versiones because we have a lot of projects and we don't want to manuelly set up the sync. process each time new project comes. 

Do you have suggestions for cross-project releases? How do you manage that? No chance we use/buy Advance Roadmaps (formerly Portfolio for Jira).

Thanks in Advance

[Nic Brough -Adaptavist- · Accepted solution]

Jira's select list custom fields do have a technical limit on the number of entries, and so do the Insight field (I believe it's the same limit)

The actual limit is far higher than the number of entries that the code would start to struggle to handle, which is a lot higher than the number your browser would start to struggle to render, which is again, a lot higher than the number your humans would start to struggle to deal with!

In other words, no, you're going to run into useability issues with very long lists well before you start running into problems with any physical limits of numbers of options.

[Andreas Lorz]

I'm completely with you. and we also recognise that 50 values is a lot for user to choose. However, since the values become no longer relevant after some time (after the release), we have the option to disable the old ones and add the new ones.

I see that this is not an optimal solution but can't figure out how to do this better.

Thanks for responding to the technical aspects!

[Nic Brough -Adaptavist-]

No problem, I think the conversation with Aron is the more useful one for getting you a good data set, I just wanted to say numbers are nothing to worry about!

One of my old clients had an array of devices to test everything against and their build servers were generating thousands of global versions every day.  Jira was fine with tens of thousands of possible entries.  The humans struggled a bit, and we ended up changing the version field to a text stamp after implementing something like Aron's suggested "release issue"

[Aron Gombas _Midori_ · Accepted solution]

Another option that I'd evaluate is using Insight to manage the "release" notion as an asset. I'd be surprised if it would limit the maximum number of assets (at least, theoretically).

[Andreas Lorz]

Hi @Aron Gombas _Midori_ 

you mean the add-on: Insight Asset Management? Is there a server version?

Thanks for the answer. We already making thoughts about add-ons but haven't had time to investigate one so far.

[Aron Gombas _Midori_]

Yes, I mean that app.

It has a Server version, but you probably know that the Server platform has became legacy.

Also, Insight has been acquired by Atlassian and it was made part of Jira Service Management somehow. (Maybe only in Premium and only on Jira Cloud, not sure.)

Another idea that came to my mind is creating a "Release" issue type, then creating issue to represent your releases and using an "Issue Picker" custom field called "Target releases" at the requirement.

[Andreas Lorz]

Yes, we are aware of it.

Your idea sounds interesting. Never thought of this. Will take that to my colleages to discussion. Thanks!