当我的软件有新版本时，Bugzilla 如何知道我现在正在开发新版本？
我正在使用 Bugzilla 和 SVN。 目前，Bugzilla 中的项目版本为 1.0 版本。 如果我决定在 SVN 2.0 版本中创建标签该怎么办？ 我如何通知 Bugzilla 我现在正在开发 2.0 版本？ 我是否只需在 Bugzilla 中编辑项目的版本号？ 但是如果用户想要提交 1.0 版本的错误怎么办？ Bugzilla 如何处理这个问题？
多谢！
I am using Bugzilla and SVN. Right now, the project version in Bugzilla is version 1.0. What if I decide to create a tag in SVN, for version 2.0. How can I notify Bugzilla that I would now be working on version 2.0? Do I simply edit the version number of the project in Bugzilla? Buut what if a user would like to file a bug for version 1.0? How can Bugzilla handle this?
Thanks a lot!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当您想要处理项目的新版本时，您可以定义一个新版本。 这允许您将错误分配给当前和/或未来版本，并指示错误将在哪些版本中修复。 这可以帮助您确定工作的优先顺序，并帮助您的用户了解计划何时修复哪些内容。 有关详细信息，请参阅文档的第 3.4.3 节。
要将 Subversion 与 Bugzilla 关联起来，您可以使用 ScmBug 或其他集成，例如 Eclipse 的 Mylyn 管理 Subversion 和 Bugzilla 之间的关系。例如，使用 Mylyn，您可以让 Bugzilla 任务“活动”在您的 Eclipse 工作区，因此任何 Subversion 提交都与该任务相关联。 developerworks 上有一篇很好的 Mylyn 简介。
当您设置关系并提交更改时，集成会将任务编号与修订相关联。
如果您想在 Subversion 中进行标记时自动创建 Bugzilla 版本，下面有一些提示，不过您可能最好手动执行此操作，因为创建标记并不意味着该产品已构建并可用于您的用户（除非您扩展挂钩来创建您的包）。
你可以为 Subversion 设置一个提交后钩子，这个钩子每当您提交更改时都会调用。 您可以检查提交类型是否是标签目录的副本，并通过 API 创建新版本。
您需要为发布标签定义一些约定，以便不会为所有标签创建版本（例如，如果标签以“release”开头，则调用 API）。
Python Subversion 扩展 pysvn 可以帮助简化您的挂钩处理。
Subversion 文档中还有一些示例脚本可以帮助您入门。
When you want to work on a new version of your project you can define a new version. This allows you to assign bugs to either the current and/or future versions, and denote in which versions the bug will be fixed. This can help prioritise your work and help your users see what is planned to be fixed when. See section 3.4.3 of the documentation for details.
To associate Subversion with Bugzilla, you can the ScmBug, or other integrations like Eclipse's Mylyn to manage the relationship between Subversion and Bugzilla.For example with Mylyn you can have the Bugzilla task "active" in your Eclipse workspace, so any Subversion commits are associated with the task. There's a nice introduction to Mylyn on developerworks.
When you have the relationship set up and commit a change, the integration will associate the task number with the revision.
If you want to automate creation of Bugzilla versions when you do the tagging in Subversion, there are some pointers below, though you are probably better doing this manually as creation of the tag doesn't mean that the product has been built and made available for your users (unless you extend the hook to also create your packages).
You can set up a post-commit hook for Subversion, this hook will be invoked whenever you commit a change. You can check if the type of commit is a copy to the tags directory and invoke Bugzilla via the API to create a new version.
You'd need to define some convention for your release tags so that versions aren't created for all tags (e.g. invoke the API if the tag starts with "release").
The Python Subversion exension pysvn can help simplify your hook processing.
There are also some example scripts in the Subversion documentation that can help you get started.
我的理解是，Bugzilla 中的版本是发现错误的版本（来自文档：存在错误的最早版本）。
我目前的做法是为每个未来版本都有一个跟踪错误，IIRC 是 Mozilla 时代处理事情的方式。
Bugzilla 此后引入了诸如目标里程碑和Flags 也可用作高级搜索中的搜索条件。
My understanding is that the Versions in Bugzilla are the versions that the bugs were found in (from the doc: the earliest version the bug was present).
My current practice is to have a tracking bug for each future version, which IIRC was the way things were handled back in the Mozilla days.
Bugzilla has since introduced concepts such as Target Milestones and Flags which can also be used as search criteria in Advanced Search.