Release 2.1.2

CHANGELOG.md

@@ -5,7 +5,7 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](http://keepachangelog.com/)
 and this project adheres to [Semantic Versioning](http://semver.org/).
 
-## [Unreleased]
+## [2.1.2] – 2019-02-17
 
 ### Added
 
@@ -136,7 +136,8 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 
 First release of Markdown Architectural Decision Records.
 
-[Unreleased]: https://github.com/adr/madr/compare/2.1.1...master
+[Unreleased]: https://github.com/adr/madr/compare/2.1.2...master
+[2.1.2]: https://github.com/adr/madr/compare/2.1.1...2.1.2
 [2.1.1]: https://github.com/adr/madr/compare/2.1.0...2.1.1
 [2.1.0]: https://github.com/adr/madr/compare/2.0.3...2.1.0
 [2.0.3]: https://github.com/adr/madr/compare/2.0.2...2.0.3

docs/adr/0000-use-markdown-architectural-decision-records.md

@@ -7,20 +7,20 @@ Which format and structure should these records follow?
 
 ## Considered Options
 
-* [MADR](https://adr.github.io/madr/) 2.1.1 - The Markdown Architectural Decision Records
+* [MADR](https://adr.github.io/madr/) 2.1.2 – The Markdown Architectural Decision Records
 * [Michael Nygard's template](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) – The first incarnation of the term "ADR"
 * [Sustainable Architectural Decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions) – The Y-Statements
 * Other templates listed at <https://github.com/joelparkerhenderson/architecture_decision_record>
 * Formless – No conventions for file format and structure
 
 ## Decision Outcome
 
-Chosen option: "MADR 2.1.1", because
+Chosen option: "MADR 2.1.2", because
 
 * Implicit assumptions should be made explicit.
   Design documentation is important to enable people understanding the decisions later on.
   See also [A rational design process: How and why to fake it](https://doi.org/10.1109/TSE.1986.6312940).
 * The MADR format is lean and fits our development style.
 * The MADR structure is comprehensible and facilitates usage & maintenance.
 * The MADR project is vivid.
-* Version 2.1.1 is the latest one available when starting to document ADRs.
+* Version 2.1.2 is the latest one available when starting to document ADRs.

package.json

@@ -11,7 +11,7 @@
     "documentation",
     "markdown"
   ],
-  "version": "2.1.1",
+  "version": "2.1.2",
   "homepage": "https://adr.github.io/madr/",
   "author": "Oliver Kopp (http://github.com/koppor/)",
   "contributors": [

template/0000-use-markdown-architectural-decision-records.md

@@ -7,20 +7,20 @@ Which format and structure should these records follow?
 
 ## Considered Options
 
-* [MADR](https://adr.github.io/madr/) 2.1.1 - The Markdown Architectural Decision Records
+* [MADR](https://adr.github.io/madr/) 2.1.2 – The Markdown Architectural Decision Records
 * [Michael Nygard's template](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) – The first incarnation of the term "ADR"
 * [Sustainable Architectural Decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions) – The Y-Statements
 * Other templates listed at <https://github.com/joelparkerhenderson/architecture_decision_record>
 * Formless – No conventions for file format and structure
 
 ## Decision Outcome
 
-Chosen option: "MADR 2.1.1", because
+Chosen option: "MADR 2.1.2", because
 
 * Implicit assumptions should be made explicit.
   Design documentation is important to enable people understanding the decisions later on.
   See also [A rational design process: How and why to fake it](https://doi.org/10.1109/TSE.1986.6312940).
 * The MADR format is lean and fits our development style.
 * The MADR structure is comprehensible and facilitates usage & maintenance.
 * The MADR project is vivid.
-* Version 2.1.1 is the latest one available when starting to document ADRs.
+* Version 2.1.2 is the latest one available when starting to document ADRs.