Release 2.0.3

adr · Mar 21, 2018 · 28f17f4 · 28f17f4
1 parent 26954e3
commit 28f17f4
Show file tree

Hide file tree

Showing 5 changed files with 18 additions and 11 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -5,6 +5,12 @@ 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/).
 
+## [2.0.3] - 2018-03-21
+
+## Fixed
+
+- Fix reference to MADR version in ADR-0000 and README.md
+
 ## [2.0.2] - 2018-03-16
 
 ### Changed
@@ -103,7 +109,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.0.2...master
+[Unreleased]: https://github.com/adr/madr/compare/2.0.3...master
+[2.0.3]: https://github.com/adr/madr/compare/2.0.2...2.0.3
 [2.0.2]: https://github.com/adr/madr/compare/2.0.1...2.0.2
 [2.0.1]: https://github.com/adr/madr/compare/2.0.0...2.0.1
 [2.0.0]: https://github.com/adr/madr/compare/1.4.0...2.0.0

diff --git a/README.md b/README.md
@@ -127,22 +127,22 @@ Which format and structure should these records follow?
 
 ## Considered Options
 
-* [MADR](https://adr.github.io/madr/) 2.0.2 - The Markdown Architectural Decision Records
+* [MADR](https://adr.github.io/madr/) 2.0.3 - 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.0.2", because
+Chosen option: "MADR 2.0.3", 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.0.1 is the latest one available when starting to document ADRs.
+* Version 2.0.3 is the latest one available when starting to document ADRs.
 ```
 
 The example is rendered at [template/0000-use-markdown-architectural-decision-records.md](template/0000-use-markdown-architectural-decision-records.md)

diff --git a/docs/adr/0000-use-markdown-architectural-decision-records.md b/docs/adr/0000-use-markdown-architectural-decision-records.md
@@ -7,19 +7,19 @@ Which format and structure should these records follow?
 
 ## Considered Options
 
-* [MADR](https://adr.github.io/madr/) 2.0.2 - The Markdown Architectural Decision Records
+* [MADR](https://adr.github.io/madr/) 2.0.3 - 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.0.2", because
+Chosen option: "MADR 2.0.3", 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.0.1 is the latest one available when starting to document ADRs.
+* Version 2.0.3 is the latest one available when starting to document ADRs.
diff --git a/package.json b/package.json
@@ -11,7 +11,7 @@
     "documentation",
     "markdown"
   ],
-  "version": "2.0.2",
+  "version": "2.0.3",
   "homepage": "https://adr.github.io/madr/",
   "author": "Oliver Kopp (http://github.com/koppor/)",
   "contributors": [

diff --git a/template/0000-use-markdown-architectural-decision-records.md b/template/0000-use-markdown-architectural-decision-records.md
@@ -7,19 +7,19 @@ Which format and structure should these records follow?
 
 ## Considered Options
 
-* [MADR](https://adr.github.io/madr/) 2.0.2 - The Markdown Architectural Decision Records
+* [MADR](https://adr.github.io/madr/) 2.0.3 - 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.0.2", because
+Chosen option: "MADR 2.0.3", 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.0.2 is the latest one available when starting to document ADRs.
+* Version 2.0.3 is the latest one available when starting to document ADRs.