How to Rename Standard 'Fix Versions' Field?

[Mo Housaini]

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.

[Nic Brough -Adaptavist- · Accepted solution]

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.

[Mo Housaini]

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.

[Nic Brough -Adaptavist-]

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.

[Mo Housaini]

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

[Alex]

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,

Alex

[Nic Brough -Adaptavist-]

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?

[Alex]

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).

[Nic Brough -Adaptavist-]

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.

[Deleted user]

"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.

[Kevin Martin]

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.

[Nic Brough -Adaptavist-]

"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"

[Katherine Brooks]

I'm glad to see that we're not the only organization that does not agree with the Fix Version/s philosophy and the system field being uneditable.

We just upgraded to Data Center after a decade of using Server (it's the government - we're not fast at upgrading). The program office has been using Fixed in Release as a system field within the field configuration. This is just the way the project has been releasing software.

I'm tempted to hide the Fixed Version/s field and create the custom Fixed in Release field, but I see warnings about the Change Log report not working. What is the project risk should I proceed with what I'm outlining?

[Nic Brough -Adaptavist-]

No risks, a new field will work fine for you.  It'll be recorded in the change log, I'm wondering what you have seen that makes you think it might not?

[Katherine Brooks]

https://confluence.atlassian.com/adminjiraserver0904/specifying-field-behavior-1188768134.html#Specifyingfieldbehavior-hidefieldHidingorshowingafield

The line that says "If you hide the Fix Version/s field, the Change Log report will not work."

[Nic Brough -Adaptavist-]

Ah, yes.  That's in the context of "the field is not there in the project" though.  If you hide a field, it can't be changed by the users, but scripts and apps can still change it.  If they do, the changes will not be recorded in the history because the field does not appear.

I tend to remove system fields from create, edit and transition screens if I want to hide them.

[Katherine Brooks]

OK, that makes sense. Thanks for the clarification.

[Marcel]

Well I must say Nic that you are not listening very well to many valid arguments. Most people are objecting the use of the word FIX as this seems odd in many companies and also translate terribly in many languages. Including my company and language. It was translated as 'herstelversie' which means more like a recovery version which seems only suitable for incidents.

It does not really help responding that it works well, it's intended that way and you have not come across any teams that don't think so. Clearly a lot of people here don't agree with you and they are probably part of a team. 

I do agree that a version is not a release but we release a version. In my opinion there does not need to be any word in front of the word Version. This would eliminate this discussion and resolve a lot of translation issues.

Proposed solution: Rename Fix Version to Version

[Nic Brough -Adaptavist-]

Hi Marcel,

I think there are a few problems here.  I do not know what the weighting between them is, but I do understand them, and I am very much listening - if I were not listening, I would not be able to explain.

Version means different things in different places in Jira.  It always means "this batch of stuff goes together to form a specific thing with a known set of content", but it can mean very different things in different places. 

I know I'm repeating myself here, but the context of how you are working is important.  A lot of places use versions as a label for "what did we actually give to people", but in some places, it is also used as "what we are aiming for".

I am 100% with you on the translation - running "fix version" through (google) translate into a language I do not speak, and then the results back into English gave some pretty poor results.  I do not know if Atlassian could do better on that, as it works fine in English, and most variants.

But, renaming it to "version" can not work.

Which version?  Is it the version(s) it affects?  The version you are going to try to fix it in?  The version it has been fixed in?  

How would that help?

[eldarj]

Fix Version indeed doesn't sound right, as it makes sense for bugs only.

Also, the idea of "I raised a new feature", "Ok, we'll fix that in version X" also doesn't make much sense and doesn't make the Fix Version field viable.

Why not call this Release Version?

That would clearly indicate that this is the version in which certain software changes were released in (or intended to be released in)

It also makes perfect sense when using Jira releases.

After all, in most scenarios the software everyone builds follows the semantic versioning - major.minor.patch - meaning that you indeed release either major changes, features, or bug fixes.

[Nic Brough -Adaptavist-]

Because it's not a release version, it's a fix version.  Not all fix versions get released, they are different things.

[Farhan Khan]

Hi, 

Just to enter my two cents on this topic, as this is becoming harder and harder to explain to our clients and stakeholders, while trying to demo a version. 

The Release function in Scrum/Kanban is using the "Fix Version" field to dictate the release or the code that is about to or already released, which includes Epics, Story, Bugs, Features, etc. 

So companies that are using the Release function to determine, or see what is part of the version was released, or even drive their Release Notes from Release Module, they are required to enter the value under Fix Version, which is hard to explain to stakeholders that Fix Version is actually the Code Version, or Release Version that the code will be promoted in. 

Yes, in the sense of bugs it makes total sense, but yet functionality is lost in translation in its true potential to create on demand reports of what goes in the Release code or Release Version.

[Nic Brough -Adaptavist-]

Yes, but Scrum and Kanban use the fix-version field differently.

In Kanban, it's pretty much what Jira was originally built for - the fix version means "we fixed it in this version"

In Kanban, usually leads to a release - the intention of Kanban is that you get stuff done and release it when ready, whereas more waterfall processes might only test a version and release only ones that pass all the testing and get through a CAB.

In Scrum, the fix version is "where we intend to fix it".  The field is set a lot earlier in the process than it is with Kanban or Waterfall.

In all of these though, a fix version is not always a release.  They are not the same thing.

[Farhan Khan]

I agree with the statements made, through the thought process of "we fixed it in this version", when there is an already built product. 

However, explaining to the stakeholders during a demo or stakeholder meeting that the new functionality that has not been built before and that will be newly released to you will be indicated through the field "Fix Versions", in the Release Notes and easily found through Issues and Filter through the field "Fix Versions" after being released for the first time.  

[eldarj]

@Nic Brough -Adaptavist- then, would you agree that Jira needs a "Release version" field?

Because it's not a release version, it's a fix version.  Not all fix versions get released, they are different things.

Not all release versions get "released" either.

Having a User story or Technical story on Jira, and using the "Fix Version" doesn't make sense. If it does, please explain how.

Renaming this field to "Release version" or just "Version" implies that a story can be of any type, while "Fix version" strictly  implies that it can only be a fix i.e. bug in question, not a user story, not a technical story, not a feature. 

Also, why does Jira link stories with "Releases" via the "Fix version"? 

[Nic Brough -Adaptavist-]

For those who want to release that way, yes, I do add field(s) for release versions.

But those would still be based on the fix version, because a release version is not the same thing - a release version might contain many fix versions.  

As I explained before, you really don't want to mix up have many field names for data that will be meaning the same thing, that just confuses people.  So while "fix" isn't maybe the right word for a story, while it is for a bug, because they mean the same thing and would want to work off the same data, it would be confusing to have different fields.  And not work for releases.

[eldarj]

But to avoid confusing people why not rename the "Fix version" field to "Release version" then? Okay, these are two different things, one release might contain multiple fixes, but I've never encountered a team or company yet that has only fixes in a release :) Otherwise, Jira then lacks the semantic capabilities to have features, improvements, etc. in a release.

[Nic Brough -Adaptavist-]

Because fix versions are not release versions, as explained before.

[eldarj]

Again, why doesn't Jira have a "Release version"? Would you say that using "Fix version" on a feature story is the correct and intended way from Jira side? 

You would only think that everyone uses "Fix version" and they are okay with that, because most people don't care. I'm yet to find a team that claims that "Fix version" makes sense - it doesn't.

[Nic Brough -Adaptavist-]

Jira doesn't have a "release version" because it wasn't needed in a simple issue tracker 20 years ago.  When it started to be a good thing to add (over affects and fix), Atlassian had no reason to do it, and a lot of partners who could.

I'm yet to find a team that does not say that "fix version" makes sense.  I do find that the teams who say it are "legacy" teams, the ones who don't "get" agile.

[eldarj]

Keeping legacy terms around just due to historic reasons is agile indeed.

[Nic Brough -Adaptavist-]

It's not a legacy term, and it's not being kept for historic reasons.  It's there because it makes sense.  Please read the previous posts again.

[myoussef]

Adding my vote to team: "Fix Version" field should be renamed to "Release Version"

> In Kanban, it's pretty much what Jira was originally built for - the fix version means "we fixed it in this version"

Doesn't make any sense for new features. "We fixed it <new feature here> in this version"

It's just causing confusion for no reason, Jira calls the same thing a "Release" (ex. in the sidebar) and a "Fix Version" (when looking at an issue's fields)

[Nic Brough -Adaptavist-]

Again, could you please read the previous posts?