We have JIRA issues with the following fields:
Affects version - version where issue is noticed
Target version - version in which we want to fix the issue
Fix version - version where issue is really fixed
The release planning is based on the fix version, I suppose per default. How could it be changed to use the target version? We set the fix version when closing an issue, so it is not at all appropriate for the planning.
"Affects version" and "Fix version" are system fields in JIRA and various screens are based on them. This is logic that you cannot change.
The "Target version" is not a default JIRA field, so it must have been added as a custom field on your instance.
Instead of trying to change the concept of a "Fix version" you're better of using it as it is intended by JIRA and customising your own logic with custom fields that you add yourself. Otherwise screens like JIRA's "Releases" view will not behave as expected.
So you should use the "Fix version" field to plan the target release and update it with the appropriate version if the actual release changes. For any other kind of version info that you like, introduce your own fields.
In the "Releases" view you can click on "View in Issue Navigator" on the right side:
This will show the JQL that is used by that view and it will show something like:
project = 12421 AND fixVersion = 17740 ORDER BY priority DESC, key ASC
This is hardcoded and I don't know of a way to customise this.
Related
Whenever there is a new release of an APK, I create a release version under the project
releases option in JIRA. And now, when creating an issue, I put the newly created version
in the affectedVersion field.
But now, when I have to search for all the issues in this version, I have to write a JQL
like project = "BA" and affectedVersion=2.0-uat-2 order BY created DESC
Is there a way to avoid writing this JQL and instead have a dropdown for affectedVersion
which shows all the versions. This way, there will not be any need to write a JQL manually
In Atlassian JIRA, what is the difference between the fields "Fix Version" and "Release Version History", and when should you use what? I cannot seem to find any definitions and recommended usage of these fields online.
This distinction is very much useful for me, especially for Epics, that span across fix versions. For example, if my Epic feature is being released in phases, e.g. 1.2.0, 1.2.1, 1.2.4 and 1.3.0, then should I:
add each release version number to "fix version" after every release, or to "release version history", or both?
If I add to only "release version history" while the Epic is in progress, then, when closing the Epic, should I update "fix version" only with that last release version number, or update "fix version" with ALL previous versions?
(Side note: I realize that maybe I am not creating Epics correctly, that an Epic should ideally be rolled out in a single release (version)? If that is the case, please do correct me.)
JIRA was originally a bug tracking system and I believe that "Fix Version" was used to indicate which version you planned to fix a bug in.
For example, a team releases version 1.1 but then a bug is reported. They raise the bug in JIRA and give it a Fix Version of 1.2 as they want the bug to be fixed in the next release.
As JIRA is now a full-blown agile project management tool, a lot of fields aren't used for their original purpose. It is really up to you to use them how you see fit. You can even add custom fields if the standard fields aren't what you want.
Ask yourself:
What information do we need?
What will this information be used for? Reporting? Analysis of trends?
Can we leverage the existing JIRA fields, or do we need to create a custom schema?
Epics are just large stories. If you are releasing every sprint then often an epic will span several releases. If you are releasing less frequently then you could aim to fit epics in to releases, but there are no hard and fast rules about this.
I have a Mantis bug tracker installed that we use for all of our products. One product goes through a rapid development cycle and each new build gets a new version number (the build number is incremented). Since our QA has to report all bugs they found for the build that introduced the bug, we also have to add a new version number to Mantis every time a new build is made. Because of this, the list of version numbers under Manage->Manage Projects->Project name is now very long.
I just tried to delete one of the very old version numbers but that removes that number from all issues that referred to it. (Makes sense from a DB design point-of-view.)
Is there a way to shorten the version list without affecting the issues? The very old version number we have will never be used again but I want the old issues intact. I did a bunch of Google searches but I keep getting flooded with unrelated results.
Did you try to set the obsolete attribute of version ?
As said in the admin guide :
Each project can have several versions, which are marked with attributes like released and obsolete.
and :
Once a version is marked as obsolete, it is now longer included in the change log.
See also these issues :
Obsolete versions not selectable as filter in `View Issues'
Versions marked as obsolete appear on change log page
If I understand you properly, what you'd like is a way to filter the versions displayed in the Manage Projects page.
This cannot be done in current version of MantisBT (1.2.14), and would require a change in the code. I suggest you open a feature request on our tracker. If you end up implementing the feature, then submit it as a pull request on our Github repository.
In TFS (2010 and up at least), we have the concept of iteration, which seems to be supposed to help assigning work (what do we do in release 1.0, what is planned for 1.1 and what is left in the backlog). I have to mention I've been looking at the Scrumm template for TFS2012.
Now, how do you classify bugs by product version?
For example, imagine we have the a product with v1.0 and v2.0 in the wild and v3.0 in developpment.
Now, we discover a bug in v1.0, and it turns out v2.0 and v3.0 also contains the bug.
Code-wise, we'll correct the bug in dev, then merge it to v1.1 and v2.1 so that our current users are not left in the cold with their version (because we cannot always mandate upgrading to the latest version).
When creating a bug in TFS, we have the option of indicating an iteration path. But we can only use one iteration, whereas we need to be able to declare the bug as existing in all three version, and mark it as corrected independently as the merges happen.
Is there any way to support that way of working in TFS, or am I looking at it wrong?
One way to accomplish this would be to modify the default Work Item Type for Bug in TFS:
In VS 2010, open the editor by choosing Tools > Process Editor >
Types > Open WIT From Server from the main menu
In the Select Work Item Type dialog, expand the Team Project
that you would like this template to apply to, select Bug and
click OK.
When the editor opens, you'll see a list of all available fields for
the Bug work item. You should notice a Found In field
available in the list. By providing the version number(s) in this
field, it should be pretty easy to write queries that can find bugs
by version.
To display this field, choose the Layout tab to bring up the
form editor. It's basically just a big tree view. Expand the group
for Group - Classification (or wherever you think this field is
most appropriate), right-click Column and choose New Control
In the attributes panel, choose Found In for the Field Name, and
also update the label.
Choose Preview Form to test your changes, then save and close
the editor
There are a number of ways around this, depending on how you choose to approach it. One is to not use the standard Areas field (Mike C suggests a good alternative). Another is to create work items to more accurately reflect the state of the work you're doing. What I mean is this:
If you're releasing a fix across three different versions of your software, I'd assume that you'd want to test it against all three versions to assume the fix is consistent across all of the codebases. A fix that worked in V1.0 may not work the same in V3.0 because the surrounding/affected code may be different.
At some point in that process you could therefore have three separate (but linked) representations of the bug: maybe three copies of the bug itself, or three test cases (one per version that the bug should be tested on) all linked to the original bug. Then, if the bug is fixed in V1.0 but requires more work to be fixed in V3.0, your work items accurately reflect this.
How do you version in JIRA when your versions are like 4.8.{TFSBuild}.{TeamCity.Build}?
Do I simply create a 4.8 Version in Jira?
However what would I set the release date to?
The problem is that our versions are dynamically and created based on the build# from tfs and the Team City build#.
What is now the best way for me to create versions in Jira?
Only the Major. Minor is hardcoded for now and for every few bug fixes we upload the release to the live server.
Jira versions are primarily a planning tool (especially if you use Greenhopper aka Agile, where you can have a version hierarchy).
So that's different from a build. It may take a thousand builds to achieve the functionality planned for a "FixFor" version.
On the other hand, "Affects" versions are used to track in which build a particular bug was found. So it'll pay to rename the "current version" (when you mark it as Released) to the actual build, as Hugo suggests. And cleanup/close/move any outstanding issues at the same time.
I would suggest to name the upcoming version that doesn't have a fixed name yet something like "Next release".
When you actually do release that version then you can change the version name in Jira to reflect the correct name.
Using Jira For Project Management - Creating Versions
We use Jira for project management of daily task assignment and we like to have versions either by week or by month. This lets us assign work for a week and is very helpful with the Greenhopper plug in. Basically, you:
Open the project from "Projects"
On left side, click on "Versions"
We have version 4.4 so might be slightly different other Jira versions.