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.
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.
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?
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.
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.
Because it's not a release version, it's a fix version. Not all fix versions get released, they are different things.
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.
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.
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
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?
There's a lot of bikeshedding about naming here. I think the solution is pretty straightforward: allow renaming Fix version field, it's trivial and solves issues when different teams have different semantics of version
It looks like you're new here. Sign in or register to get started.
