tickets linked to multiple versions

[ittayd@…]

As far as I understand, bug 2945 dealt only with description changes for requirement issues.

I have a different scenario. Say I have a project with versions 1.0, 1.0.1, 1.0.2 and 1.1. a bug is found in 1.0. it is fixed in some way in 1.0.2 and in another way in 1.1

What I'd like to have is the ability to see all open bugs in 1.0 or 1.0.1 (the above bug included), in 1.0.2 (the above bug is fixed, and the comment describing the fix affects 1.0.2) and 1.1 (the bug is fixed in another way)

I think it means only the ability to associate status changes with a version. maybe also priority and severity (in the above scenario, the fix in 1.0.2 may have been partial, not exactly closing the bug for the 1.0.x stream, but lowering the priority)

[cboos]

I don't think this has anything to do with #2945, which was about being able to use the ticket system as a requirement tool, where the ability to track the requirements changes is essential.

You actually requested to be able to associate multiple versions to a single ticket.

This was recently discussed on the trac-dev MailingList, see googlegroups:trac-dev:e253522ba63fa792 and Sergey and my replies.

On a related note, it's maybe worthwhile to consider unification of versions and milestones. Version would be the version in which the problem/RFE occurs, Milestone would be the version in which the problem/REF is fixed/implemented.

Instead of the current devel version (whose meaning change over time and has therefore not much more value than the suggested production) version, btw), we would simply use the currently developed version.

e.g. use 0.11 when trunk is 0.11dev. That way, with the unification, we'd have Version: 0.11 and Milestone: 0.11 for a problem that occurred/discovered during the development of 0.11 and fixed before the version was delivered (i.e. milestone was closed).

The above suggestion (which should maybe have its own ticket) would further simplify the current Trac model, and I think would be a prerequisite for implementing support for multiple versions per tickets, as this is the way many other BugTrackingSystem do.

[cboos]

#4308 marked as duplicate.

I'll follow up on the idea expressed there: one should be able to select multiple versions ("(+) Add Version"), and for each version added, one should be able to select a milestone, i.e. the corresponding version that has a fix.

e.g.

 Version: 0.10.1    Scheduled for Milestone: 0.10.4
 Version: 0.11      Fixed in Milestone: 0.11

with the corresponding form:

 Version: |0.10.1|    Milestone: |0.10.4|   Fixed: [ ]      (-)
 Version: |0.11|      Milestone: |0.11|     Fixed: [x]      (-)
 Version: |<version list>| (Add)

Deleting a Version/Milestone entry (-) would require confirmation.

The only difficult part I see is what happens when someone adds Version 0.10.2? #4308 suggests the notion of branches, in which case this version could be appended to 0.10.1 (displays Version: 0.10.1, 0.10.2 ...).

Defining such a branch could be relatively easy, as I suggested in the mailing list thread linked above: on create/edit milestone, there would be a "Follows Milestone |<milestone-list>|". If nothing is selected, this means that milestone/version starts a new branch.

Of course, there are other considerations to take into account than just the milestone/version association, which are the workflow ones. A simple way to address them is to consider that if the workflow needs to be different for each branch (different owner/accept state), then different tickets are needed as well. Otherwise, for small/medium project, when it's usually the same person addressing a given ticket in stable and devel, the same workflow state could apply for all branches (possibly with a flag indicating whether the issue is actually fixed for each given branch, as suggested in the illustration above).

[moo]

the idea came in into my mind was simple, but it get harder when i get deep into it.

the initial proglram was "duplicating tickets just for many branches is just superfluous". and yes, many company do it by copying tickets by duplicating it in another ticket repo, even with test director. the developers get bore seeing same tickets more and more once after they fix it.

i wouldn't suggest to use add/- unless the branch notion is hard to be implemented or hard to be used, although i wonder if some project will make the branch tree too big. listing all the active branches in "ticket form" would be nice and acceptable, while all of them can be default to "empty", which will be recorded as nothing in database.

btw, the milestone should be relatived to version if possible, with 0.10 splited into 0.10.1 and 0.11, u can select milestone 0.10.4 and 0.11 for version 0.10, i.e.: 0.10->0.10.1->..., 0.10->0.11->0.11.1->..; but not if it was splited from 0.9, i.e.: 0.9->0.10->0.10.1->..., 0.9->0.11->0.11.1->...