diff --git a/CHANGELOG.md b/CHANGELOG.md
index f193150e..0ef1b88c 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,49 +1,30 @@
-# Changelog
+# Change Log
All notable changes to this project will be documented in this file.
-## 0.0.3 - 2014-08-09
-
-### Added
-- "Why should I care?" section mentioning The Changelog podcast.
-
-### Deprecated
-- Nothing.
+## 0.0.4 - 2014-08-09
+### 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
-- Nothing.
+- 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.
-### Fixed
-- Nothing.
+## 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.
-### Deprecated
-- Nothing.
-
-### Removed
-- Nothing.
-
-### Fixed
-- Nothing.
-
-
## 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?"
-
-### Deprecated
-- Nothing.
-
-### Removed
-- Nothing.
-
-### Fixed
-- Nothing.
diff --git a/index.html b/index.html
index 029d314b..92cc2afa 100644
--- a/index.html
+++ b/index.html
@@ -25,34 +25,35 @@ Why should I care?
(fitting, right?) podcast about why open source maintainers and
contributors should care, and the motivations behind this project.
If you can spare the time (1:06), it’s a good listen.
-What makes up a good CHANGELOG?
-I’m glad you asked.
+What makes a good CHANGELOG?
+I’m glad you asked.
+A good CHANGELOG sticks to these principles:
- It’s made for humans, not machines, so legibility is crucial.
+- Easy to link to any section (hence Markdown over plain text).
- One sub-section per version.
-- Versions should come with a release date in a sensible format: YYYY-MM-DD.
-- Changes should be grouped to describe their impact on the project:
+
- List releases in reverse-chronological order (newest on top).
+- Write all dates in
YYYY-MM-DD format. (Example: 2012-06-02 for June 2nd, 2012.) It’s international, sensible, and language-independent.
+- Explicitly mention whether the project follows Semantic Versioning.
+- Each version should:
+- List its release date in the above format.
+- Group changes to describe their impact on the project, as follows:
Added for new features.Deprecated for once stable features removed in upcoming releases.Deprecated for once-stable features removed in upcoming releases.Removed for deprecated features removed in this release.Fixed for any bug fixes.Security to invite users to upgrade in case of vulnerabilities.
-- Each section should be easily linked to — hence Markdown over plain text.
-- Write release dates in an international, sensible, and language-independent
-format:
2012-06-02 for June 2nd, 2012.
-- Order the releases reverse chronologically (latest at the top).
-It’s also good to explicitly mention whether the project follows Semantic Versioning.
How can I minimize the effort required?
-Always have an "Unreleased" section at the top for keeping notes on any
+
Always have an "Unreleased" section at the top for keeping track of any
changes.
This serves two purposes:
- People can see what changes they might expect in upcoming releases
-- At release time, you just have to change "Unreleased" to the version number
-and add a new "Unreleased" header at the top.
+- At release time, you just have to change
"Unreleased" to the version number
+and add a new "Unreleased" header at the top.
What makes unicorns cry?
Alright…let’s get into it.