Include tickets that have a version but not a milestone in the progress of the version

[Lucas Rangit MAGASWERAN]

Tickets that have a version set but no milestone do not get included in the version progress bar.

Is it possible to include those tickets in the computation of the version progress?

Thanks for the great plugin!

[Lucas Rangit MAGASWERAN]

I'm not able to figure out how to do this but it got me thinking. Why not just use the ticket status directly since tickets have a version set instead of iterating through each milestones tickets?

[Lucas Rangit MAGASWERAN]

To work around this for now and instead of adding a catchall milestone for each version I added this to the version description so that is shows up on the versions page and version details. It uses the ProgressMeterMacro and shows the progress of tickets for this version regardless if a milestone is set.

• [query:?group=priority&version=release1 Tickets (with or without milestone)]:
• [[ProgressMeter(version=release1)]]

[Malcolm Studd]

Conceptually, the way I think of version and milestone for tickets is this:

• the version is the release a bug was found in
• the milestone is the target completion for the ticket

I'm not sure your suggestion would work in this case:

1. release version 1.0
2. user finds bug, opens ticket against version 1.0
3. bug is triaged to be fixed in version 1.1

I do like the workaround. I've had thoughts to put essentially that into the plugin itself: a separate progress bar and list of tickets opened on the version.

I would use the tickets associated with a version as a metric of the quality of that version. If we ever get around to switching to Trac at work, we will use a bugfixes milestone for each version.

[Malcolm Studd]

Oh, and I'm glad you like the plugin! I just wish it would make its way up my priority list enough for me to finish the features I want. :-)

[Lucas Rangit MAGASWERAN]

Replying to mestudd:

Conceptually, the way I think of version and milestone for tickets is this:

• the version is the release a bug was found in
• the milestone is the target completion for the ticket

I understand my confusion. I've been thinking of version as "target version" as opposed to "reported version". I see what you mean though; This gives you a metric as how many tickets went against a particular version.

I've implemented Trac at my work for a small team with hand full of projects. In one project we use the milestones to schedule tickets but with this new project we're starting I'm trying to use your plugin.

I've defined versions as a high-level deliverable with a short description and a due date. Tickets are assigned a "target version" and they are reflected in the overall status. For more granular status of a version, such as a group of dependencies between tickets, we optionally create milestones and assign them a version. This allows contributors to see at a glance what makes up the overall status of a version. Using components for this did not work since they would be essentially redundant since the milestone is more of an integration of multiple components.

It's all very ad-hoc but Trac and your plugin have proved to be extremely flexible and accommodating. Do you have any recommendations on how I can better use Trac and your plugin?

Should I make the feature request to add a "reported" and "target" version report?

[Grayside]

We use Version to mark the release the issue will first be part of.

However, we have a custom field that we use to "schedule" tickets to be associated with a particular Version. This is alongside the milestones, which we use as projects and schedule with this plugin.

I would love to "scope shift" this ticket to allow for arbitrary query elements to be used to add additional Or'd constraints to the primary version progressmeter. #10350 is a more versatile variation of this request.