代码之家 › 专栏 › 技术社区 › Newtopian

如何跟踪Bugzilla中的版本?

bugzilla versioning

Newtopian · 技术社区 · 16 年前

我们有一个已经存在很长时间的遗留应用程序。事实上,我们的版本管理经过了几次迭代,它在野外生成了许多不同的版本。更糟糕的是,由于合同限制,并不总是能够将客户机升级到最新和最大版本,因此我们必须在他们当前拥有的版本上进行分支、修复、测试和发布,从而产生另一个版本号。

最终的结果是版本组合框长得离谱。最后,出于各种原因,我们希望跟踪三种不同的版本信息: 发现缺陷的版本(版本)、我们计划修复缺陷的版本(里程碑)以及最终修复缺陷的版本(可接受建议)。这是我的问题,事实上。。。这实际上可以是多个数字,我们对其中一些客户进行了追溯修复(这种情况经常发生)。

这就是我需要你们集体智慧的地方:

您如何跟踪这些版本(已发现、已计划和已发布)

链接版本和bug跟踪的最佳实践是什么?

答案

似乎为每个版本克隆bug是一种很好的跟踪方法,因此目标版本总是在里程碑中以及固定版本中跟踪,而bug版本总是本地版本。

虽然我已经接受了答案,但我仍然欢迎你的意见。

4 回复 | 直到 10 年前

Andrzej Doyle 16 年前

一般来说,对于版本跟踪,我觉得这是一种合理的方法,因为我们通常只需要在任何时候支持2-3个主要版本(加上主干)。如果您有多个不相交的版本需要支持,例如特定于客户的部署,那么情况将更难跟踪。(可以说,这将在总体上造成令人头痛的问题,最好将事情统一到一个更中心的版本主题)。

devio 16 年前

我使用Bugzilla不仅跟踪bug,还跟踪新特性、增强和模糊的想法。对于每一个计划和发布的版本,我都有一个跟踪Bug(我在最初的Mozilla bugzilla上看到了这一点,并且发现它很有用)。

因此,如果您有一个bug报告,您可以输入带有报告版本号的bug。创建额外的bug(每个计划修复的版本一个),这些bug都依赖于(阻止)原始bug,并阻止特定于版本的跟踪bug。

Shiun 13 年前

我在TFS中寻找类似的功能,在进行一些调查时,我发现Bugzilla中有一个管理“目击”的增强请求: “Bug 55970-(bz分支)Bugzilla需要更好地处理分支(实现发现)”: https://bugzilla.mozilla.org/show_bug.cgi?id=55970

关于信息,我们将在TFS 2010中实现类似的功能,使用“Bug父级”或“Bug主级”来保存有关Bug本身的信息(复制步骤、严重性、技术信息、受影响的组件…),可以有“Bug child”或“Sighting”类型的子级来保存特定于给定分支的信息(目标里程碑、优先级、该分支机构的具体信息…)。

Peter Kahn 16 年前

谁使用版本以及如何使用版本?

我们使用的是一个4dectet版本(major.minor.patch.buildNO)。buildNo是生成时的SVN头部修订。每个版本都存储在JIRA中,问题有一个影响版本,并在版本字段中修复,该字段为多选。

过了一会儿,我们有了许多版本。Jira确实允许我们通过两种方式控制列表 1.存档版本(从选择列表中灰显) 2.合并版本(将多个版本合并为一个新版本-无撤消)

我们使用了归档,但由于缺少撤消,所以避免了合并。所以我们还有很多版本的列表。

如果我已经发布了,我是否需要知道在开始和发布之间有17个构建?我是否需要保留在构建1中发现的bug、在构建2中修复的bug、在构建7中再次发现的bug、在构建9中再次修复的bug的知识?或者1.0.1版中的1.0.0版是否足够好?

今天晚些时候我会问一个关于这个话题的大问题,但我已经知道了基本答案: 这取决于你的团队想要跟踪的方式。

实现很有趣,但归根结底是需求、目标以及从用户体验到解决方案的转换。当人们不一定知道该如何使用他们不太愿意使用的形式的东西时,这是很粗糙的。