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.
Related
Is there a way to sort the list of project spaces in Bitbucket? We started using Bitbucket for just a small section of the company now the entire company uses it and we have about 40 project spaces and Bitbucket and the order seems random. The original projects added years back are on the bottom (when we started using Stash 3.x) and all the newer ones (since upgrading to 4.x) are ordered alphabetically on top.
I'm sure I can poke around in the database to solve this but I'm looking for a UI- or API-based solution.
Projects in Bitbucket Server should sort in alphanumeric order. If you're not seeing that, you're experiencing a bug.
I work for Atlassian and I found and reported just such a bug when Bitbucket 5.0 was released. If perchance you're running one of the affected versions, you can resolve it by upgrading to a more recent version.
If you're running an older version than the ones listed in the above bug report, it's still possible you're running into a similar or the same bug - we list "affected versions" based on customer reports, so it's possible the bug existed on an older version but was never reported. On that bug report I provided a python script to easily reproduce the issue on a test instance, so if you can tell me the version of Bitbucket your company is running I can test it to see if it's reproducible.
We've been using Jira for a number of years now, and one of the challenges we've had is our build team had been generating daily build numbers for versions in the specific software product versions.
i.e.
t 5.0 rev 1.0001
When we have a customer facing build, we make a new version.
c 5.0 rev 1
when we release a final build, we renumber it to be:
v 5.0
When files are checked into a build, our build management automatically generates a version in the project, but we don't want to lose the build numbering when we merge versions.
Equally, we'd like the fields to be as easily searchable as versions are currently.
We aren't using Jira-Agile (aka Jira Software) at present, but that's an option.
I just don't know if Sprint versions will give us the flexibility we will need.
Has anyone got any thoughts on this, and how we would best be able to capture that requirement?
If you have one release per sprint then it would be possible to have a sprint name that followed your version syntax (e.g. sprint name = "t 5.0 rev 1.0001").
This won't give you much flexibility though, say if you needed to do an emergency bug fix release mid-sprint. It also won't allow you to track the daily build version increments.
Other things worth considering:
You could use custom fields for release type, version number and build number. The main advantage of this approach is that you could potentially use the JIRA API to have the build system update issues with the latest build number. It would be possible to then have a concatenated field that contained the entire version that would be easily searchable.
Another thing worth considering is using labels. For example you could have labels for the different types (customer facing, release, etc.). This won't make searching particularly user friendly though.
We have recently transitioned from Gemini to TFS for application change control. There is one aspect of TFS I can't get my head around - the lack of a built-in concept of the application version that each work item will be addressed in.
In Gemini every feature request, enhancement, bug etc can be tagged with a version number. If the field was left blank, the item was "unscheduled", i.e. on the backlog. Each version could be flagged as either released or not. Reports could be then created listing the issues addressed in each released version, i.e. release notes, and the issues to be addressed in future versions, i.e. a roadmap. I was completely happy with this!
Now in TFS I can't find any built-in concept of version. It seems like there are 2 ways to represent version:
As a parent item in the iteration tree, e.g.
Version 1.0.0
Sprint 1
Sprint 2
etc
Version 1.1.0
Sprint 3
Sprint 4
etc
As a parent item in the work items tree, e.g.
Version 1.0.0
Requirement 1
Requirement 2
etc
Version 1.1.0
Requirement 3
Bug 4
etc
The latter approach looks better because it allows versions to be worked on simultaneously (e.g. a major release will be worked on at the same time as bug-fix release).
So what is the recommended approach to managing work by version?
Finally, with the version property not actually being present in the work item itself, is it possible to make reports on issues addressed in each version?
For now I am going to use iteration path to capture the version number. This doesn't lend itself so well to managing development on different versions concurrently, but we are trying to get away from that practise (i.e. be working on the next release while simultaneously working on multiple bug fixes to past releases) and adopt short release cycles, i.e. a more linear path, so maybe that is a good thing.
Earlier I though Area Path might be a good place to put Version, but its too valuable as a way to split up a huge application into parts to sacrifice for versioning.
1. Tags (TFS 2013+) are the easiest way to append metadata such as build#. (same as mentioned above.)
2. The CMMI Process Template > Requirement and Bug Work Item Types have an "Integrated In" field that links to TFS Builds for direct correlation from requirement to build# [to related code changes] [to related test cases [to related test results]]. Note you must select from retained TFS Build system builds (that have not been deleted). This hard reference drop-down limits this field significantly over time or if you use a different build system. (That and build versioning are entirely different discussions :-).) The Build CMMI template fields have been there since TFS2010.
3. Create a custom field in your User Story and Bug work items. BuildImplementedIn or similarly named field would do. Creating custom fields is not hard in TFS. You will need a Team Project Admin or possibly a TPC Admin to make the customization if you aren't already an admin.
p.s.: Sorry for the late reply. I posted this answer in case others still have the same or similar question.
You could use the area field.
We use that one for product name (we maintain multiple products) and then version goes into the description of the story, but you could use the area field for versions.
Another possibility is to use tags at the top of the Product Backlog Item.
Btw, I agree that TFS is lacking a few important fields (custom fields)
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.