From 46da84292d1475e8f50c97fd4137b432e46b5f29 Mon Sep 17 00:00:00 2001 From: Olivier Lacan Date: Tue, 6 Oct 2015 18:41:05 -0400 Subject: [PATCH] Should you ever rewrite a change log? --- CHANGELOG.md | 6 ++++++ README.md | 13 +++++++++++-- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index b31a0769..3157e3cc 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -3,8 +3,14 @@ All notable changes to this project will be documented in this file. This project adheres to [Semantic Versioning](http://semver.org/). ## [Unreleased] + +## [0.1.0] - 2015-10-06 +### Added +- Answer "Should you ever rewrite a change log?". + ### Changed - Improve argument against commit logs. +- Start following [SemVer](http://semver.org) properly. ## [0.0.8] - 2015-02-17 ### Changed diff --git a/README.md b/README.md index de42738e..28185de1 100644 --- a/README.md +++ b/README.md @@ -61,8 +61,8 @@ Alright…let’s get into it. another, it should be painfully clear when something will break. - **Dates in region-specific formats.** In the U.S., people put the month first ("06-02-2012" for June 2nd, 2012, which makes *no* sense), while many people - in the rest of the world write a robotic-looking "2 June 2012", yet pronounce - it differently. "2012-06-02" works logically from largest to smallest, doesn't + in the rest of the world write a robotic-looking "2 June 2012", yet pronounce + it differently. "2012-06-02" works logically from largest to smallest, doesn't overlap in ambiguous ways with other date formats, and is an [ISO standard](http://www.iso.org/iso/home/standards/iso8601.htm). Thus, it is the recommended date format for change logs. @@ -138,6 +138,15 @@ The `[YANKED]` tag is loud for a reason. It's important for people to notice it. Since it's surrounded by brackets it's also easier to parse programmatically. +### Should you ever rewrite a change log? +Sure. There are always good reasons to improve a change log. I regularly open +pull requests to add missing releases to open source projects with unmaintained +change logs. + +It's also possible you may discover that you forgot to address a breaking change +in the notes for a version. It's obviously important for you to update your +change log in this case. + ### How can I contribute? This document is not the **truth**; it’s my carefully considered opinion, along with information and examples I gathered.