I am looking for a way to group together the issues that are planned for an upcoming release. Searching the forums, I saw two methods being suggested.
1. Create a "master issue" and then add all targeted issues as children of it (this is what the Mantis project does)
2. Fill in the "Fixed in Version" field early
Method (1) is okay but clumsy, since everyone must remember the magic issue number in order to query for issues withing a particular release. Also, there is no way to bulk assign a number of issues as a child of another issue. Method (2) is okay but then you lose the ability to state which build contains the fix (assuming multiple builds leading up to a release).
One approach that I did not see mentioned is to create a new subproject for each release, and then move issues between the main project and these version subprojects. Is there a reason why people are not using that approach? Just want to know what to look out for before we go down this road.
Thanks!
Tracking "Issues In Version"
Moderators: Developer, Contributor
method 3
heres what we are doing:
3. Make a new Custom Field: "To be fixed in Version" and populate it with candidate release versions (ie., 1.0.1). You have to toggle this value for each bug but this can be made easier by taking advantage of the batch operations in the view_all_bug_page.
BTW, I have also added another custom field "Fixed in build" since Mantis provides only a "Fixed in Version" field, which we use only for major version numbers (1.0.0) and not build numbers (123). separating version 1.0.0.123 into these two fields.
Our workflow seems to go smoothly using this method, although we have only had it in place for about a month now. The subproject approach sounds intriguing. did you try it? any caveats?
3. Make a new Custom Field: "To be fixed in Version" and populate it with candidate release versions (ie., 1.0.1). You have to toggle this value for each bug but this can be made easier by taking advantage of the batch operations in the view_all_bug_page.
BTW, I have also added another custom field "Fixed in build" since Mantis provides only a "Fixed in Version" field, which we use only for major version numbers (1.0.0) and not build numbers (123). separating version 1.0.0.123 into these two fields.
Our workflow seems to go smoothly using this method, although we have only had it in place for about a month now. The subproject approach sounds intriguing. did you try it? any caveats?
Subprojects work well
We did end up using subprojects, and they work very well. We have a top-level project which works as a catch-all for enhancement requests and issues not tied to any particular version. For each new version we create a subproject and move over any issues planned for that release. We use the version numbering in "Manage > Projects" to supply build numbers for the "Product Version" and "Fixed In Version" fields. Does that make sense? So our projects look like this:
Omega
- 1.0
- 1.1
- 1.2
Inside the 1.0 subproject, we've defined the versions 1.0.1, 1.0.2, etc. for identifying builds. If you "View Issues" on Omega you see where everything is assigned. Reporting is easy. It works great.
Omega
- 1.0
- 1.1
- 1.2
Inside the 1.0 subproject, we've defined the versions 1.0.1, 1.0.2, etc. for identifying builds. If you "View Issues" on Omega you see where everything is assigned. Reporting is easy. It works great.