Can we please get clarification on what the max configurable project key length will be. Is it 255 as some comments in some pages suggest? thanks!

Humans?! What?

Well that's another whole set of use cases!
Humans are always so complicated (err, special!).

Good response Nic.

Ellen, I think people want longer names for human reasons. Jira doesn't care if a short-codes are WORLDAPPLICATION, WORLDWIDGET, WORLDGLOBE, or EGHTFRG. But that example from one of my clients is exactly the case. Replacing short-ish, snappy, informative names with meaningless strings is a downgrade for the humans. They like words. The new nomenclature is pretty much useless for places that like long names for good reasons, and going back to a human friendly one is needed.

interesting thread - amazing.

JIRA ID nomenclature is not much different than part-number or model-number nomenclature (for ex), something that's been around for a million years in eng. and product dev. Since Ford made the first car or earlier!

I am stunned that orgs need JIRA IDs over 10 chars, or even 20 or 43!
Seems some similar numbering governance would be useful in these cases.

Fair argument that migrating old version keys (from JIRA rels's when no restriction) into a new nomenclature is a pain - and possibly a huge pain for some.

But maybe eating some pain today for a better tomorrow would be a useful exercise for your JIRA?

OR - to accommodate longer, at the UI level, it displays 1st 10 chars w/"more" symbol, when exceeds?

Having a UI display restriction is reasonable for Atlassian though, TOTALLY, imho.

Just a thought -

I vote for keeping APIs stable mid-releases, fwiw..
Took forever to get this stability years back, and glad for it since JIRA 5.X+ especially.

Thanks Bob, I should have acknowledged more explicitly that I also agree with the "stable API" and that is the reason why I am proposing the two step implementation to maintain that philosophy. I should have included the API change in the second step as well.

I do no understand the reference to the stable API for not making a change earlier. This change to restrict was made in a couple of mid version 5 releases. And it still allows for existing keys to be longer than 10 if created before the restriction. What stable API(s) are affected that were not already affected by the restriction?

What about doing this task in two steps, so some of us who cannot upgrade until this is fixed, can do so.

The first step is to make any screen adjustments so larger project keys will display correctly and either remove the limit or set the limit larger than 10. You got the data here to pick a number. If you need to have a limit then tell us where that number is located (hopefully, the database or a text file and not java code) we do not need the admin interface to make the adjustments right away.
A database style solution should work for OnDemand as well, since support could update the number for the customer if customers have issues.

The second step is the admin interface which can wait until whatever major version you decide to implement it. Atlassian generally does not make commitments when something will be done especially things on major revisions.

I think the concept that this issue is a MAJOR SHOWSTOPPER for existing customers is getting lost in the discussion.

Hi All,

Thanks for everyone's feedback via the comments.

We've made the project key a configurable option (by admins) in the next major release - JIRA 6.0. We were unable to put this into a minor release or point release because it included changes to our stable API. Our rule is that breakages to APIs can only be done in major releases.

Cheers everyone,

Roy Krishna
JIRA Product Management

Already tried: nope. That would have been surprising anyway, as the issue is still considered Open...

Is this problem solved in the new JIRA version (5.2)?