Feature #1675
Add 'affected version' as a standard field
| Status: | New | Start: | 2008-07-23 | |
| Priority: | Normal | Due date: | ||
| Assigned to: | - | % Done: | 0% |
|
| Category: | Custom fields | |||
| Target version: | - | |||
| Resolution: |
Description
As described in this forum post , the way the Redmine project uses affected versions isn't usable by any redmine installation that has multiple projects.
Because custom fields are not on a per-project basis, we'd have to have separate 'project X affected version' and 'project Y affected version' fields as each project has different version numbers.
Affected version could be a standard field on all projects that have a 'target version' field. That way you can easily do a query on all issues that exist in a particular release.
Related issues
| related to Feature #1245 | close versions | New | 2008-05-16 | ||
| related to Feature #685 | New Custom Field "Found in Version" | New | 2008-02-18 | ||
| related to Feature #284 | Issues fixed in multiple versions | New | |||
| related to Feature #1266 | Feature: Allow setting multiple target-milestones | New | 2008-05-20 |
History
2008-07-23 12:19 - Russell Hind
Related this to issue 1245 as the issue came up in the comments for that issue too.
2008-08-04 03:11 - Mischa The Evil
+1 Though this seems to be also becoming difficult due to the fact that you can have multiple branches (versions) out in the field which are indeed affected by one issue. Also those versions can be "closed" already.
So do we allow this "affected version" field to contain multiple versions for one issue? And do we allow issues with the affected version set to a "closed" version?
Also important to mention in this issue is that this "affected version" field should ideally populate it's contents from the project's versions...
2008-08-04 23:01 - Sven Schuchmann
I think it is enough to allow only one version to be affected.
I already mentioned a "found in version" field which seems to be the same as "affected version" over here #685
2008-08-05 01:22 - Nick Read
Sven Schuchmann wrote:
I think it is enough to allow only one version to be affected.
Strongly disagree. Working on a large project that has many version in the field, it is common that an issue is reported by different customers and affect multiple released versions. Add to this any unreleased versions that our internal QA team finds.
This same logic can (and should) be applied for multiple fixed versions (for different branches), as can be seen in my feature request in #284 and comment in #1266.
2008-08-05 05:10 - Mischa The Evil
Nick Read wrote:
Sven Schuchmann wrote:
I think it is enough to allow only one version to be affected.
Strongly disagree. Working on a large project that has many version in the field, it is common that an issue is reported by different customers and affect multiple released versions. Add to this any unreleased versions that our internal QA team finds.
This same logic can (and should) be applied for multiple fixed versions (for different branches), as can be seen in my feature request in #284 and comment in #1266.
I agree with Nick.
2008-08-05 09:45 - Russell Hind
Nick Read wrote:
Strongly disagree. Working on a large project that has many version in the field, it is common that an issue is reported by different customers and affect multiple released versions. Add to this any unreleased versions that our internal QA team finds.
This same logic can (and should) be applied for multiple fixed versions (for different branches), as can be seen in my feature request in #284 and comment in #1266.
While I agree that issues will be found in multiple versions and also therefore fixed in multiple versions, that can already be achieved by relating tickets and therefore creating multiple tickets, one for each version it was fixed in. That way, you have a specific ticket to close when you merge the fix to the appropriate stable branch.
I'd be happy with it implemented either way, but if a single affected version and target version would make it easier (therefore quicker) to implement, then I'd be happy with that.
Cheers
Russell
2008-08-05 16:15 - Mischa The Evil
Russell Hind wrote:
Nick Read wrote:
Strongly disagree. Working on a large project that has many version in the field, it is common that an issue is reported by different customers and affect multiple released versions. Add to this any unreleased versions that our internal QA team finds.
This same logic can (and should) be applied for multiple fixed versions (for different branches), as can be seen in my feature request in #284 and comment in #1266.
While I agree that issues will be found in multiple versions and also therefore fixed in multiple versions, that can already be achieved by relating tickets and therefore creating multiple tickets, one for each version it was fixed in. That way, you have a specific ticket to close when you merge the fix to the appropriate stable branch.
I'd be happy with it implemented either way, but if a single affected version and target version would make it easier (therefore quicker) to implement, then I'd be happy with that.
If you look at it that way i'm going to doubt since that approach could be workable too imo. Though I'd then recommend to add a specific issue-relation for this kind of ticket-branch_relationship.
Either way it will be a change to redmine with a higher severity imo. At the moment I'd vote therefor to further discuss the pros and cons of either implementation before changing anything already :-)
2008-08-06 01:26 - Nick Read
Russell Hind wrote:
Nick Read wrote:
....
While I agree that issues will be found in multiple versions and also therefore fixed in multiple versions, that can already be achieved by relating tickets and therefore creating multiple tickets, one for each version it was fixed in. That way, you have a specific ticket to close when you merge the fix to the appropriate stable branch.
I'd be happy with it implemented either way, but if a single affected version and target version would make it easier (therefore quicker) to implement, then I'd be happy with that.
See comment no.3 in #1266 for my reasons against this data duplication against tickets. Tickets are not a static thing; they get added to, edited, moved around. Unless the relation type is special enough to perform automatic data updates across the related tickets, then it's not suitable. I think I'm going to have to rewrite my multi-fixed versions patch for the latest trunk - the same logic could be used for a multi-affected versions patch.