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

自动生成“此版本的新增功能”阅读

  •  4
  • lunohodov  · 技术社区  · 16 年前

    我们都知道这一点——这本书列出了我们最喜欢的软件的每个新版本所带来的变化。当它打包成文件时( 改变TXT , 变化 , TXT 等)或在安装程序中显示,这通常是安装/更新前我们首先阅读的内容。

    在当前项目中,我们有一个 更改日志.txt 每次发生显著变化时都会手动更新的文件。然而,这常常导致“我忘记更新变更日志”。所以我正在寻找一种自动化的方法。

    我正在考虑一个脚本,它从提交消息中提取更改(使用约定)并生成文件。例如,提交消息

    将json glib更新为0.7.6

    [更改]

    _¼修复车窗碰撞

    _¼用非常大的uid修复Facebook联系人的问题。

    将生成以下内容 改变TXT

    版本1.9.18(2010年10月3日)

    • 修复Windows崩溃
    • 使用非常大的uid解决Facebook联系人的问题。

    有人知道更好的解决方案/工具吗?还是我自己写?

    谢谢!

    4 回复  |  直到 14 年前
        1
  •  3
  •   David Wengier    16 年前

    您可以根据您的bug跟踪系统中的描述自动生成它,以查找在此版本中标记为已修复的bug。如果您将bug与功能请求区分开来,那么您也可以标记它。

    我对bug使用mantisbt,它会自动为您生成一个现成的变更日志。

        2
  •  3
  •   Jay Zhu    16 年前

    我认为变更日志应该只捕获版本中的主要变更/缺陷修复。把所有东西都放在变更日志里根本没有意义。它使变更日志不可读,最终变得无用。

    从变更列表注释生成变更日志也可能会将应用程序的实现详细信息泄漏给最终用户。

    在一个版本中,通常有两种类型的开发开发,从带来用户价值的角度来看:

    1. 新特点
    2. 影响较大的缺陷修复。

    我认为上面的内容应该足够好,可以作为一个变更日志。像“代码重构”这样的更改可能对内部开发人员有好处,但对最终用户没有任何意义,因此不应出现在更改日志中。

    对于新特性,我们通常可以通过设计文档跟踪它,设计文档最终会传输到新特性列表。

    对于缺陷修复,我确信您必须使用某种缺陷跟踪系统。用一些特定的标签标记那些显著的缺陷。您可以对自上次发布以来关闭的这些缺陷进行查询。

    希望这有帮助。

        3
  •  1
  •   Tomislav Nakic-Alfirevic    16 年前

    没有更好的方法来确保涵盖我所知道的一切。也就是说,假设您可以让每个人编写有意义的提交消息。

    例如,mercurial和subversion特别适用于提交日志的后处理:mercurial,因为它可以使用 template mechanism 和Subversion,因为它可以将log-in.xml转储,然后可以相对容易地对其进行处理,以生成更改日志的第一个草稿。

        4
  •  0
  •   Vladimir    16 年前

    如果您不想让客户看到 全部的 已修复的问题(可能没有),可以定义一个名为 包括在变更日志中 您选择的问题跟踪工具中的字段,并自动生成文档,其中只包含这些字段。

    这通常包括客户报告的问题和可能重要的新功能。

    推荐文章