version 2.2

12 files changed, 57 insertions, 68 deletions

diff --git a/README.md b/README.md
index cfd647ad..bdc382e9 100644
--- a/README.md
+++ b/README.md
@@ -84,7 +84,7 @@ The framework can be used like any other if you don't want/need to mix productio
 [![download](https://img.shields.io/badge/download%20%20-latest-blue.svg)](https://raw.githubusercontent.com/onqtam/doctest/master/doctest/doctest.h)
 [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/503/badge)](https://bestpractices.coreinfrastructure.org/projects/503)
 [![Join the chat at https://gitter.im/onqtam/doctest](https://badges.gitter.im/onqtam/doctest.svg)](https://gitter.im/onqtam/doctest?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
-[![Try it online](https://img.shields.io/badge/try%20it-online-orange.svg)](https://wandbox.org/permlink/A0brgIKrY4lVbcb6)
+[![Try it online](https://img.shields.io/badge/try%20it-online-orange.svg)](https://wandbox.org/permlink/WpIiohiJKefTZnRI)
 <!--
 [![Language](https://img.shields.io/badge/language-C++-blue.svg)](https://isocpp.org/)
 [![documentation](https://img.shields.io/badge/documentation%20%20-online-blue.svg)](https://github.com/onqtam/doctest/blob/master/doc/markdown/readme.md#reference)
diff --git a/doc/html_generated/assertions.html b/doc/html_generated/assertions.html
index 3681dabc..d42fd3a3 100644
--- a/doc/html_generated/assertions.html
+++ b/doc/html_generated/assertions.html
@@ -39,7 +39,7 @@ CHECK(thisReturnsTrue());
 REQUIRE(i < 42);
 ```
 
-Negating asserts - ```<LEVEL>_FALSE(expression)``` - evaluates the expression and records the _logical NOT_ of the result.
+- Negating asserts - ```<LEVEL>_FALSE(expression)``` - evaluates the expression and records the _logical NOT_ of the result.
 
 These forms exist as a workaround for the fact that ```!``` prefixed expressions cannot be decomposed properly.
 
@@ -49,7 +49,8 @@ Example:
 REQUIRE_FALSE(thisReturnsFalse());
 ```
 
-Note that these asserts also have a ```_MESSAGE``` form - like ```CHECK_MESSAGE(expression, message)``` which is basically a code block ```{}``` with a scoped [**```INFO()```**](logging.html#info) logging macro together with the ```CHECK``` macro - that way the message will be relevant only to that assert. All the other binary/unary/fast asserts don't have this variation.
+- Using the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) config option can make compilation of asserts up to [**31-63%**](benchmarks.html#cost-of-an-assertion-macro) faster!
+- These asserts also have a ```_MESSAGE``` form - like ```CHECK_MESSAGE(expression, message)``` which is basically a code block ```{}``` with a scoped [**```INFO()```**](logging.html#info) logging macro together with the ```CHECK``` macro - that way the message will be relevant only to that assert. The binary/unary asserts don't have this variation yet.
 
 Examples:
 
@@ -67,7 +68,7 @@ For more information about the ```INFO()``` macro and logging with the streaming
 
 These asserts don't use templates to decompose the comparison expressions for the left and right parts.
 
-These have the same guarantees as the expression decomposing ones - just less templates - [**25%-45% faster**](benchmarks.html#cost-of-an-assertion-macro) for compile times.
+These have the same guarantees as the expression decomposing ones but [**57-68% faster**](benchmarks.html#cost-of-an-assertion-macro) for compilation.
 
 ```<LEVEL>``` is one of 3 possible: ```REQUIRE```/```CHECK```/```WARN```.
 
@@ -80,24 +81,7 @@ These have the same guarantees as the expression decomposing ones - just less te
 - ```<LEVEL>_UNARY(expr)``` - same as ```<LEVEL>(expr)```
 - ```<LEVEL>_UNARY_FALSE(expr)``` - same as ```<LEVEL>_FALSE(expr)```
 
-## Fast asserts
-
-These are the faster versions of the binary and unary asserts - by [**60-80%**](benchmarks.html#cost-of-an-assertion-macro) of compile time.
-
-The difference is they don't evaluate the expression in a ```try/catch``` block - if the expression throws the whole test case ends.
-
-There is also the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) config identifier that makes them even faster by another [**50-80%**](benchmarks.html#cost-of-an-assertion-macro)!
-
-```<LEVEL>``` is one of 3 possible: ```REQUIRE```/```CHECK```/```WARN```.
-
-- ```FAST_<LEVEL>_EQ(left, right)``` - almost the same as ```<LEVEL>(left == right)```
-- ```FAST_<LEVEL>_NE(left, right)``` - almost the same as ```<LEVEL>(left != right)```
-- ```FAST_<LEVEL>_GT(left, right)``` - almost the same as ```<LEVEL>(left >  right)```
-- ```FAST_<LEVEL>_LT(left, right)``` - almost the same as ```<LEVEL>(left <  right)```
-- ```FAST_<LEVEL>_GE(left, right)``` - almost the same as ```<LEVEL>(left >= right)```
-- ```FAST_<LEVEL>_LE(left, right)``` - almost the same as ```<LEVEL>(left <= right)```
-- ```FAST_<LEVEL>_UNARY(expr)``` - almost the same as ```<LEVEL>(expr)```
-- ```FAST_<LEVEL>_UNARY_FALSE(expr)``` - almost the same as ```<LEVEL>_FALSE(expr)```
+Using the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) config option can make the binary asserts to compile up to [**84-91%**](benchmarks.html#cost-of-an-assertion-macro) faster!
 
 ## Exceptions
 
@@ -138,7 +122,7 @@ Asserts can be used outside of a testing context (in code not called from a ```T
 
 A ```doctest::Context``` object still has to be created somewhere and set as the default one using the ```setAsDefaultForAssertsOutOfTestCases()``` method - and then asserts will work. A handler can be registered by calling the ```setAssertHandler()``` method on the context object. If no handler is set then ```std::abort()``` is called on failure.
 
-The results would be best when using the [**fast asserts**](assertions.html#fast-asserts) coupled with the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) config identifier and by defining your own macro aliases - like shown [**here**](../../examples/all_features/doctest_proxy.h).
+The results would be best when using the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) config identifier.
 
 Checkout the [**example**](../../examples/all_features/asserts_used_outside_of_tests.cpp) showcasing how that is done. For more information see the [**issue for the feature request**](https://github.com/onqtam/doctest/issues/114).
 
diff --git a/doc/html_generated/benchmarks.html b/doc/html_generated/benchmarks.html
index 3dd49fda..26fe3a38 100644
--- a/doc/html_generated/benchmarks.html
+++ b/doc/html_generated/benchmarks.html
@@ -23,7 +23,7 @@ Environment used (Intel i7 3770k, 16g RAM):
 - Windows 7 - on an SSD
 - Ubuntu 17.04 in a VirtualBox VM - on a HDD
 
-**doctest** version: 2.0.0 (released on 2018.08.23)
+**doctest** version: 2.2.0 (released on 2018.12.02)
 
 [**Catch**](https://github.com/philsquared/Catch) version: 2.3.0 (released on 2018.07.22)
 
@@ -103,9 +103,9 @@ The script generates 11 ```.cpp``` files and in 10 of them makes 50 test cases w
 
 **doctest** specific:
 
+- **+faster 1** - will add [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) to speed up the compilation of the normal asserts ```CHECK(a==b)```
 - ```CHECK_EQ(a,b)``` - will use ```CHECK_EQ(a,b)``` instead of the expression decomposing ones
-- ```FAST_CHECK_EQ(a,b)``` - will use ```FAST_CHECK_EQ(a,b)``` instead of the expression decomposing ones
-- **+faster** - will add [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) which speeds up ```FAST_CHECK_EQ(a,b)``` even more
+- **+faster 2** - will add [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) to speed up the compilation of the binary asserts ```CHECK_EQ(a,b)```
 - **+disabled** - all test case and assert macros will be disabled with [**```DOCTEST_CONFIG_DISABLE```**](configuration.html#doctest_config_disable)
 
 [**Catch**](https://github.com/philsquared/Catch) specific:
@@ -113,16 +113,16 @@ The script generates 11 ```.cpp``` files and in 10 of them makes 50 test cases w
 - **+faster** - will add [**```CATCH_CONFIG_FAST_COMPILE```**](https://github.com/philsquared/Catch/blob/master/docs/configuration.html#catch_config_fast_compile) which speeds up the compilation of the normal asserts ```CHECK(a==b)```
 - **+disabled** - all test case and assert macros will be disabled with **```CATCH_CONFIG_DISABLE```**
 
-| doctest             | baseline | ```CHECK(a==b)``` | ```CHECK_EQ(a,b)``` | ```FAST_CHECK_EQ(a,b)``` | +faster | +disabled |
-|---------------------|----------|-------------------|---------------------|--------------------------|---------|-----------|
-| MSVC Debug          |    2.60 |   26.47 |   16.66 |    7.27 |    4.85 |    1.95 |
-| MSVC Release        |    3.02 |   58.13 |   25.66 |   10.37 |    6.29 |    1.74 |
-| MinGW GCC Debug     |    3.65 |   93.97 |   58.46 |   23.82 |   11.41 |    1.60 |
-| MinGW GCC Release   |    3.92 |  276.09 |  150.53 |   48.41 |   17.48 |    1.96 |
-| Linux GCC Debug     |    2.34 |   92.38 |   53.10 |   17.95 |    9.76 |    1.21 |
-| Linux GCC Release   |    3.05 |  249.08 |  122.91 |   31.90 |   19.44 |    1.76 |
-| Linux Clang Debug   |    2.33 |   82.15 |   49.46 |   18.46 |    8.26 |    1.47 |
-| Linux Clang Release |    3.10 |  151.88 |   76.89 |   20.47 |   11.53 |    1.73 |
+| doctest             | baseline | ```CHECK(a==b)``` | +faster 1 | ```CHECK_EQ(a,b)``` | +faster 2 | +disabled |
+|---------------------|----------|-------------------|-----------|---------------------|-----------|-----------|
+| MSVC Debug          |    2.69 |   27.37 |   10.37 |   17.17 |    4.82 |    1.91 |
+| MSVC Release        |    3.15 |   58.73 |   20.73 |   26.07 |    6.43 |    1.83 |
+| MinGW GCC Debug     |    3.78 |   97.29 |   43.05 |   59.86 |   11.88 |    1.67 |
+| MinGW GCC Release   |    4.09 |  286.70 |   95.42 |  156.73 |   18.16 |    2.03 |
+| Linux GCC Debug     |    2.39 |   91.36 |   41.92 |   52.26 |   10.16 |    1.32 |
+| Linux GCC Release   |    3.29 |  257.40 |   97.46 |  128.84 |   19.38 |    1.79 |
+| Linux Clang Debug   |    2.40 |   85.52 |   43.53 |   51.24 |    8.32 |    1.62 |
+| Linux Clang Release |    3.40 |  160.65 |   79.34 |   81.52 |   11.90 |    1.82 |
 
 And here is [**Catch**](https://github.com/philsquared/Catch) which only has normal ```CHECK(a==b)``` asserts:
 
@@ -144,15 +144,15 @@ And here is [**Catch**](https://github.com/philsquared/Catch) which only has nor
 **doctest**:
 
 - is between 0 and 8 times faster than [**Catch**](https://github.com/philsquared/Catch) when using normal expression decomposing ```CHECK(a==b)``` asserts
-- asserts of the form ```CHECK_EQ(a,b)``` with no expression decomposition - around 31%-63% faster than ```CHECK(a==b)```
-- fast asserts like ```FAST_CHECK_EQ(a,b)``` with no ```try/catch``` blocks - around 64-86% faster than ```CHECK_EQ(a,b)```
-- the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) identifier which makes the fast assertions even faster by another 55-78%
-- using the [**```DOCTEST_CONFIG_DISABLE```**](configuration.html#doctest_config_disable) identifier the assertions just disappear as if they were never written - even lower than the baseline (because most of the implementation is also gone)
+- asserts of the form ```CHECK_EQ(a,b)``` with no expression decomposition - around 31-63% faster than ```CHECK(a==b)```
+- the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) identifier makes the normal asserts faster by 57-68%
+- the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) identifier makes the binary asserts even faster by another 84-91%
+- using the [**```DOCTEST_CONFIG_DISABLE```**](configuration.html#doctest_config_disable) identifier the asserts just disappear as if they were never written - even lower than the baseline (because most of the implementation is also gone)
 
 [**Catch**](https://github.com/philsquared/Catch):
 
-- using [**```CATCH_CONFIG_FAST_COMPILE```**](https://github.com/philsquared/Catch/blob/master/docs/configuration.html#catch_config_fast_compile) results in 10%-30% faster build times for asserts (and in one case 73%).
-- using the **```CATCH_CONFIG_DISABLE```** identifier provides the same great benefits for assertion macros as the doctest version ([**```DOCTEST_CONFIG_DISABLE```**](configuration.html#doctest_config_disable)) - unlike in the case for the header cost
+- using [**```CATCH_CONFIG_FAST_COMPILE```**](https://github.com/philsquared/Catch/blob/master/docs/configuration.html#catch_config_fast_compile) results in 10-30% faster build times for asserts (and in one case 73%).
+- using the **```CATCH_CONFIG_DISABLE```** identifier provides the same great benefits for assert macros as the doctest version ([**```DOCTEST_CONFIG_DISABLE```**](configuration.html#doctest_config_disable)) - but not for the header cost
 
 ## Runtime benchmarks
 
diff --git a/doc/html_generated/configuration.html b/doc/html_generated/configuration.html
index b4173822..fcaffa06 100644
--- a/doc/html_generated/configuration.html
+++ b/doc/html_generated/configuration.html
@@ -98,9 +98,11 @@ This should be defined globally.
 
 ### **```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**
 
-This makes the fast assert macros (```FAST_CHECK_EQ(a,b)``` - with a ```FAST_``` prefix) compile [**even faster**](benchmarks.html#cost-of-an-assertion-macro)! (50-80%)
+This config option makes the assert macros (except for those dealing with exceptions) compile [**much faster**](benchmarks.html#cost-of-an-assertion-macro)! (XX-XX%)
 
-Each fast assert is turned into a single function call - the only downside of this is: if an assert fails and a debugger is attached - when it breaks it will be in an internal function - the user will have to go 1 level up in the callstack to see the actual assert.
+Each assert is turned into a single function call - the only downside of this is: if an assert fails and a debugger is attached - when it breaks it will be in an internal function - the user will have to go 1 level up in the callstack to see the actual assert.
+
+It also implies [**```DOCTEST_CONFIG_NO_TRY_CATCH_IN_ASSERTS```**](#doctest_config_no_try_catch_in_asserts) (so exceptions thrown during the evaluation of an assert are not caught by the assert itself but by the testing framework - meaning that the test case is immediately aborted).
 
 This can be defined both globally and in specific source files only.
 
@@ -142,10 +144,12 @@ This should be defined only in the source file where the library is implemented
 This will remove all ```try``` / ```catch``` sections from:
 
 - the [normal asserts](assertions.html#expression-decomposing-asserts)
-- the [binary and unary asserts](assertions.html#binary-and-unary-asserts) - making them functionally the same as the [**fast asserts**](assertions.html#fast-asserts) (but not for compile time speed)
+- the [binary and unary asserts](assertions.html#binary-and-unary-asserts)
 
 so exceptions thrown while evaluating the expression in an assert will terminate the current test case.
 
+This can be used for some mild compile time savings but for greater impact look into [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts).
+
 This can be defined both globally and in specific source files only.
 
 ### **```DOCTEST_CONFIG_NO_EXCEPTIONS```**
diff --git a/doc/html_generated/faq.html b/doc/html_generated/faq.html
index 285ca471..000237b9 100644
--- a/doc/html_generated/faq.html
+++ b/doc/html_generated/faq.html
@@ -52,25 +52,26 @@ A quick and easy way to migrate most of your Catch tests to doctest is to change
 ```
 #include "path/to/doctest.h"
 
-#undef TEST_CASE
-#define TEST_CASE(name, tags) DOCTEST_TEST_CASE(tags " " name) // will concatenate the tags and test name string literals to one
 #define SECTION(name) DOCTEST_SUBCASE(name)
-using doctest::Approx; // catch exposes this by default outside of its namespace
 
+// only if tags are used: will concatenate them to the test name string literal
+#undef TEST_CASE
+#define TEST_CASE(name, tags) DOCTEST_TEST_CASE(tags " " name)
+
+// catch exposes this by default outside of its namespace
+using doctest::Approx;
 ```
 
 ### How to get the best compile-time performance with the framework?
 
-Using the [**fast**](assertions.html#fast-asserts) asserts in combination with [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) yelds the [**fastest**](benchmarks.html#cost-of-an-assertion-macro) compile times.
-
-There are only 2 drawbacks of this approach:
+The [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) config option yelds the [**fastest possible**](benchmarks.html#cost-of-an-assertion-macro) compile times (up to 31-91%). Also the expression-decomposing template machinery can be skipped by using the [**binary**](assertions.html#binary-and-unary-asserts) asserts.
 
-- using fast asserts (60-90% [**faster**](benchmarks.html#cost-of-an-assertion-macro) than ```CHECK(a==b)```) means that there is no ```try/catch``` block in each assert so if an expression throws the whole test case ends.
-- defining the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) config identifier will result in even [**faster**](benchmarks.html#cost-of-an-assertion-macro) fast asserts (50-80%) at the cost of only one thing: when an assert fails and a debugger is present - the framework will break inside a doctest function so the user will have to go 1 level up in the callstack to see where the actual assert is in the source code.
+There are only 2 tiny drawbacks of using this config option:
 
-These 2 things can be considered negligible if you are dealing mainly with arithmetic (expressions are unlikely to throw exceptions) and all the tests usually pass (you don't need to often navigate to a failing assert with a debugger attached)
+- there is no ```try/catch``` block in each assert so if an expression is thrown the whole test case ends (but is still caught and reported).
+- when an assert fails and a debugger is present - the framework will break inside a doctest function so the user will have to go 1 level up in the callstack to see where the actual assert is in the source code.
 
-If you want better aliases for the asserts instead of the long ones you could use [**```DOCTEST_CONFIG_NO_SHORT_MACRO_NAMES```**](configuration.html#doctest_config_no_short_macro_names) and then define your aliases like this: ```#define CHECK_EQ DOCTEST_FAST_CHECK_EQ``` (example in [**here**](../../examples/all_features/alternative_macros.cpp) and [**here**](../../examples/all_features/doctest_proxy.h)).
+These 2 things can be considered negligible and totally worth it if you are dealing mainly with expressions unlikely to throw exceptions and all the tests usually pass (you don't need to navigate often to a failing assert with a debugger attached).
 
 ### Is doctest thread-aware?
 
diff --git a/doc/html_generated/features.html b/doc/html_generated/features.html
index 4055962d..af76df74 100644
--- a/doc/html_generated/features.html
+++ b/doc/html_generated/features.html
@@ -37,7 +37,7 @@
 	- all tests built and ran in **Debug**/**Release** modes
 	- all tests ran through **valgrind** under **Linux** (sadly [not under OSX](https://github.com/onqtam/doctest/issues/11))
 	- all tests ran through **address**, **UB** and **thread** sanitizers under **Linux**/**OSX**
-	- tests are ran in more than **168** different configurations on UNIX (Linux + OSX) on **travis** CI
+	- tests are ran in more than **140** different configurations on UNIX (Linux + OSX) on **travis** CI
 	- tests are ran in a total of **10** different configurations on Windows on **appveyor** CI
 
 ## Other features:
diff --git a/doc/html_generated/roadmap.html b/doc/html_generated/roadmap.html
index 08beabb6..25b85e70 100644
--- a/doc/html_generated/roadmap.html
+++ b/doc/html_generated/roadmap.html
@@ -12,7 +12,7 @@ This library is free, and will stay free but needs your support to sustain its d
 
 Planned features for future releases - order changes constantly...
 
-### For 2.1:
+### For 2.3:
 
 - finish the reporter system
     - what is done:
@@ -36,7 +36,7 @@ Planned features for future releases - order changes constantly...
         - documentation
 - matchers - should investigate what they are - look at google test/mock and Catch (also predicates and boost test)
 
-### For 2.2:
+### For 2.4:
 
 - header with extensions
     - demangling with the use of the cxxabi header
@@ -66,7 +66,7 @@ Planned features for future releases - order changes constantly...
         - https://www.jetbrains.com/clion/features/unit-testing.html
         - https://blog.jetbrains.com/clion/2017/03/clion-2017-1-released/#catch
 
-### For 2.3:
+### For 2.5:
 
 - log levels - like in [boost test](http://www.boost.org/doc/libs/1_63_0/libs/test/doc/html/boost_test/utf_reference/rt_param_reference/log_level.html)
 - running tests a [few times](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.html#repeating-the-tests)
@@ -93,6 +93,7 @@ Planned features for future releases - order changes constantly...
 
 - use modules - use ```std::string``` and whatever else comes from the standard - no more hand rolled traits and classes
 - minimize the use of the preprocessor
+- remove backwards-compatible macros for the fast asserts
 
 ### Things that are being considered but not part of the roadmap yet:
 
@@ -148,7 +149,7 @@ Planned features for future releases - order changes constantly...
         - http://preshing.com/20111124/always-use-a-lightweight-mutex/
         - http://preshing.com/20120226/roll-your-own-lightweight-mutex/
 - ability to provide a temp folder that is cleared between each test case
-- make the _MESSAGE assert macros work with variadic arguments - and maybe write the ones for binary/unary/fast asserts as well
+- make the _MESSAGE assert macros work with variadic arguments - and maybe write the ones for binary/unary asserts as well
 - move from operator "<<" to "<=" for capturing the left operand when decomposing binary expressions with templates
 - think about silencing warnings about unused variables when DOCTEST_CONFIG_DISABLE is used - see commit 6b61e8aa3818c5ea100cedc1bb48a60ea10df6e8 or issue #61
     - also this: ```(void)(true ? (void)0 : ((void)(expression)))```
@@ -161,7 +162,6 @@ Planned features for future releases - order changes constantly...
 ### Things that are very unlikely to enter the roadmap:
 
 - rethink static code analysis suppressions - users shouldn't have to use the same flags for code which uses doctest macros/types
-- think about removing the binary asserts (leaving only the fast binary asserts) because normal asserts + no try/catch in asserts are almost the same
 - move the "react()" part (the one that throws for REQUIRE asserts - or for when "abort-after=<int>" is reached) to a function call in the while() part of the asserts
 - stop using underscores for the begining of identifiers - the anonymous variables - against the standard...
 - templated fixture test cases
diff --git a/doc/html_generated/tutorial.html b/doc/html_generated/tutorial.html
index ab9a62e9..73f89e12 100644
--- a/doc/html_generated/tutorial.html
+++ b/doc/html_generated/tutorial.html
@@ -77,7 +77,7 @@ Although this was a simple test it's been enough to demonstrate a few things abo
 1. All we did was ```#define``` one identifier and ```#include``` one header and we got everything - even an implementation of ```main()``` that will respond to command line arguments. You can only use that ```#define``` in one source file for (hopefully) obvious reasons. Once you have more than one file with unit tests in you'll just ```#include "doctest.h"``` and go. Usually it's a good idea to have a dedicated implementation file that just has ```#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN``` and ```#include "doctest.h"```. You can also provide your own implementation of main and drive **doctest** yourself - see [**supplying your own ```main()```**](main.html).
 2. We introduce test cases with the ```TEST_CASE``` macro. It takes one argument - a free form test name (for more see [**Test cases and subcases**](testcases.html)). The test name doesn't have to be unique. You can run sets of tests by specifying a wildcarded test name or a tag expression. See the [**command line**](commandline.html) docs for more information on running tests.
 3. The name is just a string. We haven't had to declare a function or method - or explicitly register the test case anywhere. Behind the scenes a function with a generated name is defined for you and automatically registered using static registry classes. By abstracting the function name away we can name our tests without the constraints of identifier names.
-4. We write our individual test assertions using the ```CHECK()``` macro. Rather than a separate macro for each type of condition (equal, less than, greater than, etc.) we express the condition naturally using C++ syntax. Behind the scenes a simple expression template captures the left-hand-side and right-hand-side of the expression so we can display the values in our test report. There are other [**assertion macros**](assertions.html) not covered in this tutorial - but because of this technique the number of them is  drastically reduced.
+4. We write our individual test assertions using the ```CHECK()``` macro. Rather than a separate macro for each type of condition (equal, less than, greater than, etc.) we express the condition naturally using C++ syntax. Behind the scenes a simple expression template captures the left-hand-side and right-hand-side of the expression so we can display the values in our test report. There are other [**assertion macros**](assertions.html) not covered in this tutorial - but because of this technique the number of them is drastically reduced.
 
 ## Test cases and subcases
 
diff --git a/doctest/doctest.h b/doctest/doctest.h
index 888ed84a..b0706822 100644
--- a/doctest/doctest.h
+++ b/doctest/doctest.h
@@ -46,9 +46,9 @@
 // =================================================================================================
 
 #define DOCTEST_VERSION_MAJOR 2
-#define DOCTEST_VERSION_MINOR 1
+#define DOCTEST_VERSION_MINOR 2
 #define DOCTEST_VERSION_PATCH 0
-#define DOCTEST_VERSION_STR "2.1.0"
+#define DOCTEST_VERSION_STR "2.2.0"
 
 #define DOCTEST_VERSION                                                                            \
     (DOCTEST_VERSION_MAJOR * 10000 + DOCTEST_VERSION_MINOR * 100 + DOCTEST_VERSION_PATCH)
diff --git a/doctest/parts/doctest_fwd.h b/doctest/parts/doctest_fwd.h
index 2a8be997..00c55740 100644
--- a/doctest/parts/doctest_fwd.h
+++ b/doctest/parts/doctest_fwd.h
@@ -43,9 +43,9 @@
 // =================================================================================================
 
 #define DOCTEST_VERSION_MAJOR 2
-#define DOCTEST_VERSION_MINOR 1
+#define DOCTEST_VERSION_MINOR 2
 #define DOCTEST_VERSION_PATCH 0
-#define DOCTEST_VERSION_STR "2.1.0"
+#define DOCTEST_VERSION_STR "2.2.0"
 
 #define DOCTEST_VERSION                                                                            \
     (DOCTEST_VERSION_MAJOR * 10000 + DOCTEST_VERSION_MINOR * 100 + DOCTEST_VERSION_PATCH)
diff --git a/examples/all_features/test_output/version.txt b/examples/all_features/test_output/version.txt
index 25bc4ef4..38b43f15 100644
--- a/examples/all_features/test_output/version.txt
+++ b/examples/all_features/test_output/version.txt
@@ -1 +1 @@
-[doctest] doctest version is "2.1.0"
+[doctest] doctest version is "2.2.0"
diff --git a/scripts/version.txt b/scripts/version.txt
index 50aea0e7..e3a4f193 100644
--- a/scripts/version.txt
+++ b/scripts/version.txt
@@ -1 +1 @@
-2.1.0
\ No newline at end of file
+2.2.0
\ No newline at end of file