How should the Version field be used in Trac?

Question

I use Trac to track bugs, and future changes in my software projects. Tickets in Trac have a "Version" field and I'm trying to figure out the best way to use this field.

Say I find a series of bugs in version 1.0 of my software. I create tickets in track for each and assign them to version 1.0. Now say I fix some of the bugs, and add some of the new features and release version 1.1. But some of the old 1.0 bugs are still in 1.1. Should I change their corresponding tickets to version 1.1 because they also now exist in 1.1? Or should I leave them set to version 1.0 as a way of tracking what version the bug was found in, and just assume that any open tickets in older versions still exist in newer versions?

Breeching

Answer 1

I would generally use the version field to indicate the version the bug was found in. I would use the milestone to indicate what version the ticket will be fixed in. If the ticket is open, it hasn't been fixed.

Tenishatenn

+1 This has been my preferred usage too. The semantics make the most sense this way, I think. – Buzz

Answer 2

One approach is to tag builds using a suitable version number. Then it's fairly easy to update the version field with a TracLink as the ticket evolves.

Addendum: Several examples of using a TracLink in the version field maybe be found in tickets associated with Trac itself. Many leave the field blank. Several, including ticket #8146, implement Trac Ticket Queries. Others point to related milestones, etc. The uses are as varied as the tickets themselves.

Dike

Yes I tag my version in SVN, but I'm new to TracLinks. I understand how they can be used to link between various elements in SVN and or Trac. However, I don't understand how they could be used to update the version field? – Breeching

I don't think a TracLink can update the version field directly, but you can adopt a policy of using a particular type of TracLink in a given type of ticket. I've added some links to the examples above. – Dike

Answer 3

There is always the possibility to update some fields directly in sqlite or mysql. if you are familiar with python you can develop a little python script which does the job. assuming you release once or twice a year...

Ignition

Answer 4

I am using version 1.0 of trac. I use the version field to indicate the first version containing the bug. I added a "fixed in version" custom field, following the guide in http://trac.edgewall.org/wiki/TracTicketsCustomFields

I defined it as follows in trac.ini:

[ticket-custom]
fixed_in_version = text
fixed_in_version.label = Fixed in version
fixed_in_version.format = reference

You can then create reports to see which issues have been closed in a particular version (useful for creating the release note).

I also extract all non-closed tickets and list them as known problems in the release note.

Ezraezri

can you explain how you can create a changleog on what tickets was fixed in what version. – Incompressible