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)

[Christian Boos]

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.

[Christian Boos]

#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→…

[anonymous]

Is there a way to make the Version and Milestone fields contain two selections from the same list? I want to be able to report and track a bug that exists in more than one version of our software and be able to assign a milestone for the bug in each of the versions. Is this kind of customization possible in Trac?

Thank you,

Marie Andrews (marie.andrews@…)

Replying to 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).

[Christian Boos]

Replying to Marie:

Is there a way to make the Version and Milestone fields contain two selections from the same list?

Not automatically, those are different things. But nothing prevents you to always create milestones and versions in pairs, with the same name.

I want to be able to report and track a bug that exists in more than one version of our software and be able to assign a milestone for the bug in each of the versions. Is this kind of customization possible in Trac?

Well, that's the topic of this open ticket, so no, not yet. One possible workaround is to create the ticket once, then clone it for each other release line (see #4686).

_{PS: don't abuse the Reply feature, only keep what's relevant to the discussion in your quote}

[Christian Boos]

Milestone 2.0 deleted

[Christian Boos]

Note that in its simplest form (JIRA's Affects Version/s: … ; Fix Version/s: …) this is a specific case for #918.

[franz.mayer@…]

Very interesting topic - exactly this feature we need quite often. Currently we clone tickets and put it into two (sometimes three) milestones.

[anonymous]

This.

We are switching from Bugzilla to Extraview due to a lack of this feature. The overhead of tracking multiple bugs(tickets) in different releases is finally too much.

I was really hoping that Trac had this feature. It is the only thing preventing us from using it.

[dake@…]

Very needed feature for anyone who needs to support bugfixes to multiple versions of the same software.

It would be nice if instead of simply having a "fixed" checkbox, the ticket could have a different state per branch - including a state like "unverified" to show that the issue may affect a branch, but it hasn't been verified yet, and a further state "affected" or "verified".

Ideally, this should have support for actual versioning system branches. I envision being able to create "release branches" in Trac and assigning SVN branches to them. We make heavy use of the CommitTicketUpdater, and it would be nice if a commit would change the status only for the branch that was, in fact, commited to.

Additionally, it would be nice if a similiar mechanism existed for merges. Our usual procedure is to commit bugfixes to trunk (assuming the problem is still present there), then merge the fix to previous release branches. While simply using a "fixes x" message would work, assuming above mentioned support for tracking commits by branch, it would be nicer if Trac showed that a fix was merged from one branch to another.

[figaro]

Referenced in #221.

As per cboos: this ticket is for assigning one ticket to multiple milestones, whereas #221 is for assigning one ticket to multiple components.