我使用 Trac 来跟踪软件项目中的错误和未来的更改。 Trac 中的门票有一个“版本”字段，我正在尝试找出使用该字段的最佳方法。
假设我在软件 1.0 版本中发现了一系列错误。我为每个项目创建了跟踪票并将它们分配给版本 1.0。现在说我修复了一些错误，并添加了一些新功能并发布了 1.1 版本。但 1.0 的一些旧 bug 仍然存在于 1.1 中。我是否应该将其相应的票证更改为 1.1 版本，因为它们现在也存在于 1.1 版本中？或者我应该将它们设置为版本 1.0 作为跟踪发现错误的版本的一种方式，并假设旧版本中的任何开放票证仍然存在于新版本中？
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?
发布评论
评论（4）
我通常会使用版本字段来指示发现错误的版本。我会使用里程碑来指示票证将在哪个版本中修复。如果票证已打开，则尚未修复。
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.
一种方法是使用合适的版本标签构建数字。然后使用
TracLink更新版本字段相当容易票证不断演变。附录：在版本字段中使用
TracLink的几个示例可在与 票据中找到rel="nofollow noreferrer">Trac 本身。许多人将该字段留空。包括 ticket #8146 在内的多个实施 Trac 票证查询。 其他指向相关的里程碑等。用途与门票本身一样多种多样。One approach is to tag builds using a suitable version number. Then it's fairly easy to update the version field with a
TracLinkas the ticket evolves.Addendum: Several examples of using a
TracLinkin 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.总是可以直接在 sqlite 或 mysql 中更新某些字段。如果你熟悉 python，你可以开发一个小的 python 脚本来完成这项工作。假设你每年发布一次或两次......
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...
我使用的是trac 1.0版本。我使用版本字段来指示包含错误的第一个版本。我按照 http://trac.edgewall.org/ 中的指南添加了“固定版本”自定义字段wiki/TracTicketsCustomFields
我在 trac.ini 中将其定义如下：
然后，您可以创建报告来查看特定版本中已关闭哪些问题（对于创建发行说明很有用）。
我还提取了所有未关闭的票证，并将它们列为发行说明中的已知问题。
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:
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.