Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How to Rename Standard 'Fix Versions' Field?

Jira Software comes with standard multi-select Fix Versions and Affects Versions fields, which allow you to choose from the Releases created for your project.


How can I rename these fields? We are using Jira Software Cloud.

1 answer

1 accepted

0 votes
Answer accepted

You can translate them by using a different language in your profile, but you cannot rename them.

What is your reason for wanting to rename the field?   It's not intended to be a release field (although releases are a sub-set of your versions), so I'm not sure what you are looking for.

You can translate them by using a different language in your profile, but you cannot rename them.

Does this mean I could provide a translation for the field in English and effectively rename it for all my users who have English selected as the language in their profile?

If so, could you let me know how or point me to the relevant documentation? 

What is your reason for wanting to rename the field? It's not intended to be a release field (although releases are a sub-set of your versions), so I'm not sure what you are looking for.

In our internal terminology we refer to these 'versions' as 'releases'. Our releases can either be unreleased, released, or archived (which are the three statuses for 'versions'). Thus I'm looking to rename this field so it better aligns with our internal language.

With the translations, technically, yes, that's exactly what you do - if you select say German, as an alternate language, then the field name will come out in whatever is in the language pack for German.

So if you could find or create a language pack for "my English where we call versions releases", you could use that, and get your people to swap from English to my-English.

There is however a problem - you can't install your own language packs on Cloud.

If you could, there's a second problem in that the UI talks about version in other places, so you wouldn't be creating a language pack with only a name change for version, you'd need to read everything that refers to version and replace it.

There's a third problem with your translation too - Jira already uses the word "release" for, well, releases.  If you just replaced version with release, you would create the problem that you can't tell the difference between a release and a version.  The most obvious thing here is that your users could see two reports saying "release report" and not know which one to use because versions are not releases.  You would need to choose another word for release (deployment maybe, although that's wrong really, I'm not very imaginitive)

It would be far better (and I don't think you have much choice), to educate your people that versions are not releases and hence should not be called that.

Thanks for letting me know Nic. Indeed making this change wouldn't be worth the effort.

Hi @Nic Brough -Adaptavist-,

I have the very same question as the inital one and my answer to "What is your reason for wanting to rename the field?" is this:

The name "Fix version" is obviously incorrect as not only bugs, but also new features are developed and documented in Jira. This is very confusing and the colleagues I introduced this to were struggling to accept that...

But I researched/googled a lot and it doesn't seem to bother most. Is this field/feature most commonly not used in real life?

A custom field is no solution as the corresponding features are linked to the system field.

Can you somehow explain why it is named liked that?

Best regards,


I've never run into another team have a problem with "fix version", and it's used a lot in Jira processes, it's not like only a fewe people use it.  It's at the heart of Kanban usage, Waterfall projects tend to like it for saying what the fix version is, and most Scrum teams use it to help with planning.  Continuous deployment systems often rely on it for identifying what they've been building and deploying.

It's a concept I ran into a few years before Jira was written, and I actually had requests to change the name of fields in other trackers to change it to "fix version"!  (Although I will say literal translations into some other languages absolutely make no sense and if you're not using English, it's well worth putting proper thought into a translation)

I'm not sure where you might be getting confused with it?  Could you explain why it's a problem?

Thanks for your reply!

Short (I already wrote that): 'Fix version' is only correct regarding 'Bugs', not in case of 'New Features'. There's no version which is 'fixed' by the new feature. No one talks like that.

Long story:

We're developing software and working with releases/versions. We document/track developments in Jira. Those developments are 'New Features' and 'Bugs'.

The developments are planned to be released with a specific version. That would be the 'target release' ('target version') or designated 'release version' or whatever. In Jira we want to assign the 'corresponding' version the feature will be developed for/released with.

For a bug you could call this the 'Fix version', but with a new feature we don't 'fix' the software, we enhance it (at least we don't talk like that, do you?).

And we have way more new features than fixes, especially in the context of planning (wich is what we do with the sprint/backlog/board/versions; bugs often go ad hoc/quick without big planning).

Now I wanted to introduce these version system fields (affected/fix) in our process/to our team and everyone was confused by the terms and unsure when to use what.

I mean, it's not a super big issue and we will get used to it, but it's just so obviously inaccurate, that I had to research/google if this is the correct field which is also used for new features.

Seems I'm alone with that issue in the community. Maybe the term sounds more inaccurate to Germans (using English though).

But if you change the "Fix version" to something that suits "new features", you make a nonsense of the name when it applies to bugs. 

You do not want fields that contain the same thing to have different names in different places, that's a really unpleasant thing to do your people (and won't work anyway - what column header would you print in a report that includes both types of issue?)

"Fix version" is not that bad for features though, so again, I wouldn't bother - think of the conversation -

  • I raised a new feature
  • Great, why?
  • The software doesn't do it
  • Ok, we'll fix that in version X

It's not a bad way to describe it for new features.  There are issue types it's better for, and some definitely poor, but that's probably true of a lot of names people use for fields.  It's not "inaccurate", just not 100% obvious in the context of that type of issue.

"Target Version" instead of "Fix Version" would indeed (and has been, for over a decade and a half) the preferred wording. :)

Both for bugs, and for features. The "Fix" part is a vestigial artifact from when Jira was just a bug tracker.

I also wish I had the user-friendly terminology customizations like Aha! provides, where I can rename 'release' to 'commitment' or 'fixversion' to 'GA target' as the language the organization prefers to use. It should just be an editable/configurable presentation attribute of an object, not a hardwired label that does not fit well with intended usage. For what it costs, a more modern view of labels should be a feature already.

"Target version" doesn't work in Kanban.

Yes, I can see good reasons to adopt local jargon, as long as the jargon is clear, and you can tell new people coming from other places that have used Jira "it's what we call X here"

Suggest an answer

Log in or Sign up to answer
Site Admin

Atlassian Community Events