自动生成“此版本中的新增功能”阅读
我们都知道 - 这是列出我们最喜欢的软件的每个新版本所带来的变化的阅读内容。每当它作为文件（Changes.txt、CHANGES、WhatsNew.txt等）捆绑在一起或出现在安装程序中时，这通常是我们在安装/更新之前阅读的第一件事。
在当前项目中，我们有一个 Changelog.txt 文件，每次发生显着更改时都会手动更新该文件。然而，这通常会导致“我忘记更新变更日志”。所以我正在寻找一种自动化的方法。
我正在考虑一个脚本，它可以从我们的提交消息中提取更改（使用约定）并生成文件。例如像这样的提交消息
将 json-glib 更新至 0.7.6
[更改]
－ 修复 Windows 上的崩溃问题
－ 修复具有非常大 UID 的 Facebook 联系人的问题。
将生成以下Changes.txt
版本 1.9.18（2010 年 3 月 10 日）
- 修复 Windows 上的崩溃问题
- 修复了 UID 过大的 Facebook 联系人的问题。
有谁知道更好的解决方案/工具，还是我要编写自己的解决方案/工具？
谢谢！
We all know it - this is the reading that lists the changes brought by each new version of our favorite software. Whenever it comes bundled as a file (Changes.txt, CHANGES, WhatsNew.txt, etc) or is presented within an installer this is usually the first thing we read before installing/updating.
On a current project we have a Changelog.txt file that gets updated by hand every time a notable change occurs. However this often leads to "I forgot to update the changelog". So I am looking for a way to automate this.
I am thinking of a script that extracts the changes from our commit messages (using a convention) and generates the file. For example a commit message like
Updated json-glib to 0.7.6
[changes]
－ Fix crash on Windows
－ Fix issues with facebook contacts with very large UIDs.
Would produce the following Changes.txt
Version 1.9.18 (03/10/2010)
- Fix crash on Windows
- Fix issues with facebook contacts with very large UIDs.
Does anyone know a better solution/tool for this or am I going to write my own?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以根据错误跟踪系统中的描述自动生成此版本中标记为已修复的错误。如果您区分错误和功能请求，那么您也可以对其进行标记。
我使用 MantisBT 来解决错误，它会自动为您生成开箱即用的变更日志。
You could auto generate it from the descriptions in your bug tracking system for bugs marked as fixed in this version. If you differentiate bugs from feature requests then you can mark that too.
I use MantisBT for bugs and that will automatically generate a changelog for you out of the box.
我认为变更日志应该只捕获版本中的主要更改/缺陷修复。将所有内容都放在变更日志中根本没有意义。它使变更日志不可读并最终变得无用。
从变更列表注释生成变更日志还可能会将应用程序的实现细节泄露给最终用户。
通常，在一个版本中，就带来用户价值而言，有两种类型的开发开发：
缺陷修复。我相信上面的内容对于变更日志来说应该足够了。像“代码重构”这样的更改可能会让内部开发人员受益，但对最终用户来说没有任何意义，因此不应出现在更改日志中。
对于新功能，通常我们可以通过设计文档进行跟踪，最终会转移到新功能列表中。
对于缺陷修复，我确信您必须使用某种缺陷跟踪系统。用一些特定的标签标记那些显着的缺陷。您可以查询自上次发布以来已关闭的这些缺陷。
希望这有帮助。
I think the Changelog should only capture major changes/defect fixes in the release. Put everything in the changelog doesn't make sense at all. It makes the changelog unreadable and eventually become useless.
Generate changelog from changelist comments may also leak implementation details of your application to the end user.
Typically in a release there are 2 types of development development, in terms of bringing user value:
I believe the content above should be good enough for a changelog. Changes like 'code refactoring' may benefit in house developers but means nothing to the end user thus should not appear in the changelog.
For the new feature typically we can track it by the design document, which will finally transfered to the new feature list.
For the defect fixing, I am sure you must be using some kind of defect tracking system. Mark those significant defect with some certain tag. And you can do a query for these defects that was closed since last release.
Hope this helps.
没有比这更好的方法来确保涵盖我所知道的一切了。也就是说，假设您可以让每个人都编写有意义的提交消息。
例如，Mercurial 和 subversion 特别适合对提交日志进行后处理：mercurial 因为它可以使用 模板机制 和颠覆，因为它可以将日志转储到 .xml 中，然后可以相对轻松地对其进行处理以生成初稿更改日志。
There's no better way to be sure of covering everything that I know of. That is, assuming you can get everyone to write commit messages that make sense.
Mercurial and subversion, for example, are especially suitable for post-processing the commit log: mercurial because it can easily configure the way it shows the log using the template mechanism and subversion because it can dump the log in .xml which can then be relatively easily processed to generate a first draft of a change log.
如果您不希望客户看到所有已修复问题的列表（可能不会），您可以在您的选择问题跟踪工具并自动生成仅包含这些字段的文档。
这通常包括客户报告的问题以及可能重要的新功能。
If you don't want your customer to see the list of all the issues that were fixed (probably not), you could define a field called include in changelog field in your issue tracking tool of choice and automatically generate the document including only these fields.
This would typically include issues reported by the customer and maybe important new features.