There is a newer version available: 简体中文 1.0.0

如何维护更新日志

更新日志绝对不应该是git日志的堆砌物

Version 0.3.0

更新日志是什么?

更新日志(Change Log)是一个由人工编辑,以时间为倒序的列表。 这个列表记录所有版本的重大变动。

# Changelog
All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

## [1.0.0] - 2017-06-20
### Added
- New visual identity by [@tylerfortune8](https://github.com/tylerfortune8).
- Version navigation.
- Links to latest released version in previous versions.
- "Why keep a changelog?" section.
- "Who needs a changelog?" section.
- "How do I make a changelog?" section.
- "Frequently Asked Questions" section.
- New "Guiding Principles" sub-section to "How do I make a changelog?".
- Simplified and Traditional Chinese translations from [@tianshuo](https://github.com/tianshuo).
- German translation from [@mpbzh](https://github.com/mpbzh) & [@Art4](https://github.com/Art4).
- Italian translation from [@azkidenz](https://github.com/azkidenz).
- Swedish translation from [@magol](https://github.com/magol).
- Turkish translation from [@karalamalar](https://github.com/karalamalar).
- French translation from [@zapashcanon](https://github.com/zapashcanon).
- Brazilian Portugese translation from [@Webysther](https://github.com/Webysther).
- Polish translation from [@amielucha](https://github.com/amielucha) & [@m-aciek](https://github.com/m-aciek).
- Russian translation from [@aishek](https://github.com/aishek).
- Czech translation from [@h4vry](https://github.com/h4vry).
- Slovak translation from [@jkostolansky](https://github.com/jkostolansky).
- Korean translation from [@pierceh89](https://github.com/pierceh89).
- Croatian translation from [@porx](https://github.com/porx).
- Persian translation from [@Hameds](https://github.com/Hameds).
- Ukrainian translation from [@osadchyi-s](https://github.com/osadchyi-s).

### Changed
- Start using "changelog" over "change log" since it's the common usage.
- Start versioning based on the current English version at 0.3.0 to help
translation authors keep things up-to-date.
- Rewrite "What makes unicorns cry?" section.
- Rewrite "Ignoring Deprecations" sub-section to clarify the ideal
  scenario.
- Improve "Commit log diffs" sub-section to further argument against
  them.
- Merge "Why can’t people just use a git log diff?" with "Commit log
  diffs"
- Fix typos in Simplified Chinese and Traditional Chinese translations.
- Fix typos in Brazilian Portuguese translation.
- Fix typos in Turkish translation.
- Fix typos in Czech translation.
- Fix typos in Swedish translation.
- Improve phrasing in French translation.
- Fix phrasing and spelling in German translation.

### Removed
- Section about "changelog" vs "CHANGELOG".

## [0.3.0] - 2015-12-03
### Added
- RU translation from [@aishek](https://github.com/aishek).
- pt-BR translation from [@tallesl](https://github.com/tallesl).
- es-ES translation from [@ZeliosAriex](https://github.com/ZeliosAriex).

## [0.2.0] - 2015-10-06
### Changed
- Remove exclusionary mentions of "open source" since this project can
benefit both "open" and "closed" source projects equally.

## [0.1.0] - 2015-10-06
### Added
- Answer "Should you ever rewrite a change log?".

### Changed
- Improve argument against commit logs.
- Start following [SemVer](https://semver.org) properly.

## [0.0.8] - 2015-02-17
### Changed
- Update year to match in every README example.
- Reluctantly stop making fun of Brits only, since most of the world
  writes dates in a strange way.

### Fixed
- Fix typos in recent README changes.
- Update outdated unreleased diff link.

## [0.0.7] - 2015-02-16
### Added
- Link, and make it obvious that date format is ISO 8601.

### Changed
- Clarified the section on "Is there a standard change log format?".

### Fixed
- Fix Markdown links to tag comparison URL with footnote-style links.

## [0.0.6] - 2014-12-12
### Added
- README section on "yanked" releases.

## [0.0.5] - 2014-08-09
### Added
- Markdown links to version tags on release headings.
- Unreleased section to gather unreleased changes and encourage note
keeping prior to releases.

## [0.0.4] - 2014-08-09
### Added
- Better explanation of the difference between the file ("CHANGELOG")
and its function "the change log".

### Changed
- Refer to a "change log" instead of a "CHANGELOG" throughout the site
to differentiate between the file and the purpose of the file — the
logging of changes.

### Removed
- Remove empty sections from CHANGELOG, they occupy too much space and
create too much noise in the file. People will have to assume that the
missing sections were intentionally left out because they contained no
notable changes.

## [0.0.3] - 2014-08-09
### Added
- "Why should I care?" section mentioning The Changelog podcast.

## [0.0.2] - 2014-07-10
### Added
- Explanation of the recommended reverse chronological release ordering.

## [0.0.1] - 2014-05-31
### Added
- This CHANGELOG file to hopefully serve as an evolving example of a
  standardized open source project CHANGELOG.
- CNAME file to enable GitHub Pages custom domain
- README now contains answers to common questions about CHANGELOGs
- Good examples and basic guidelines, including proper date formatting.
- Counter-examples: "What makes unicorns cry?"













为何要提供更新日志?

为了让用户和开发人员更好知道每一个版本有哪些区别。

为何我要在乎呢?

因为归根结底软件是为人提供的。既然你不关心人,那么为何写软件呢? 多少你还是要关心你的受众。

本文档原作者和另外两个人的一个播客向大家介绍了, 为何代码的管理者和开发者应该在乎更新日志。如果你有一小时时间和很好的英文听力本领, 不妨听听。

怎么定义好的更新日志

好问题!

一个好的更新日志,一定满足:

怎么尽可能减少耗费的精力?

永远在文档最上方提供一个'Unreleased' 未发布区域,来记录当前的变化。 这样作有两大意义。

吐槽环节到了

请你一定要注意:

如果你还有要吐槽的,欢迎留issue或者直接PR

世界上不是有标准的更新日志格式吗?

貌似GNU或者GNU NEWS还是提过些规范的,事实是它们太过简陋了。 开发有那么多种情况,采用那样的规范,确实是不太合适的。

这个项目提供的规范是作者本人希望能够成为世界规范的。 作者不认为当前的标准足够好,而且作为一个社区,我们是有能力提供更棒的规范。 如果你对这个规范有不满的地方,不要忘记还可以吐槽呢。

更新日志文件名应该叫什么?

我们的案例中给的名字就是最好的规范:CHANGELOG.md,注意大小写。

HISTORY.txt, HISTORY.md, History.md, NEWS.txt, NEWS.md, News.txt, RELEASES.txt, RELEASE.md, releases.md这么 多文件名就太不统一了。

只会让大家更难找到。

为何不直接记录git log?

因为git日志一定是乱糟糟的。哪怕一个最理想的由完美的程序员开发和提交的,哪怕一个 从不忘记每次提交全部文件,不写错别字,不忘记重构每一个部分,也无法保证git日志完美无瑕。 况且git日志的核心在于记录代码的演化,而更新日志则是记录最重要的变更。

就像注释之于代码,更新日志之于git日志。前者解释为什么,而后者说明发生了什么

更新日志能机器识别吗?

非常困难,因为有各种不同的文件格式和其它规范。

Vandamme是一个Ruby程序(由Gemnasium团队制作),可以解析 好多种(但绝对不是全部)开源库的更新日志。

到底是CHANGELOG还是更新日志

CHANGELOG是文件名,更新日志是常用说法。CHANGELOG采用大写是有历史根源的。就像很多类似的文件 READMELICENSE,还有CONTRIBUTING

采用大写可以更加显著,毕竟这是项目很重要的元信息。就像开源徽章

那些后来撤下的版本怎么办?

因为各种安全/重大bug原因被撤下的版本被标记'YANKED'。这些版本一般不出现在更新日志里,但作者建议他们出现。 显示方式应该是:

## 0.0.5 - 2014-12-13 [YANKED]

[YANKED]采用大写更加显著,因为这个信息很重要。而采用方括号则容易被程序解析。

是否可以重写更新日志

当然。哪怕已经上线了,也可以重新更新更新日志。有许多开源项目更新日志不够新,所以作者就会帮忙更新。

另外,很有可能你忘记记录一个重大功能更新。所以这时候应该去重写更新日志。

如何贡献?

本文档并不是真理。这只是原作者的个人建议,并且包括许多收集的例子。 哪怕本开源库提供一个更新日志案例,我刻意没有提供一个 过于苛刻的规则列表(不像语义化版本格式)。

这是因为我希望通过社区达到统一观点,我认为中间讨论的过程与结果一样重要。

所以欢迎贡献