Merge branch 'release/0.2.0'

.travis.yml

@@ -1,6 +1,9 @@
 # reference: http://www.objc.io/issue-6/travis-ci.html
 
 language: objective-c
-before_install: cd Example && pod install && cd -
+before_install:
+  - brew update # workaround for #2836
+  - if brew outdated | grep -qx xctool; then brew upgrade xctool; fi # workaround for #2836
+  - cd Example && pod install && cd -
 script:
 - xctool test -workspace Example/HRSCustomErrorHandling.xcworkspace -scheme HRSCustomErrorHandling -sdk iphonesimulator ONLY_ACTIVE_ARCH=NO

CHANGELOG.md

@@ -1,5 +1,13 @@
 #Changelog
 
+The versioning in this project is based on [Semantic Versioning](http://semver.org).
+
+## v0.2.0
+Introduce a new api to present view controller based errors. This api is especially made for overriding and displaying custom error dialogs, such as [TSMessages](https://github.com/toursprung/TSMessages). The default implementation looks the same as the regular api but is only shown if the passed-in view controller is visible.
+
+## v0.1.2
+*There are no changes to the source code in this release. Only the Podfile.lock of the example project has been updated.*
+
 ## v0.1.1
 - Minor fixes to support travis-ci as continuous integration server
 - Reformat the documentation comments to support cocoadocs parsing

CONTRIBUTING.md

@@ -2,14 +2,14 @@
 
 Contribution to this project is very welcome. You do not need to submit code to participate in this project, every bug you find and every improvement idea you have brings this project forward. Feel free to send your issues and pull requests to this project through GitHub. The project maintainer will comment on issues and pull requests as necessary.
 
-However, please note that not every pull request might get merged into the project. Even though we value your contribution to this project a lot, the project maintainer does look very carefully at every pull request and makes sure that it improves the project in a whole and does not break with any old behavior for compatibility reasons. We find it very important to provide the same quality and compatibility in our own frameworks that Apple provides in their own APIs. Therefore we might ask you to change a couple of things before a pull request is merged. These changes can lead from simple formatting or commit message fixes to general architectural changes. This is done to make sure, the code is readable and consistent. If you want to make sure that a pull request would be of interest for the project, feel free to file an improvement through the 'Issues' section to discuss your idea.
+However, please note that not every pull request might get merged into the project. Even though we value your contribution to this project a lot, the project maintainer does look very carefully at every pull request and makes sure that it improves the project in a whole and does not break with any old behavior for compatibility reasons. All our projects are used inside our own applications, so it is very important to us, to maintain a high quality standard, which you are participating from as well. We find it very important to provide the same quality and compatibility in our own frameworks that Apple provides in their own APIs. Therefore we might ask you to change a couple of things before a pull request is merged. These changes can lead from simple formatting or commit message fixes to general architectural changes. This is done to make sure, the code is readable and consistent. If you want to make sure that a pull request would be of interest for the project, feel free to file an improvement through the 'Issues' section to discuss your idea.
 
 
 ## Issues
 
 Please do not hesitate to post an issue for every bug or improvement you find. Before opening a new issue please check the existing issues to prevent filing duplicates.
 
-Do not post general questions to the 'Issues' section but instead ask on Stack Overflow for general help. For project specific questions do not hesitate to contact the project maintainer directly but be aware that you might not get an answer immediately. Questions posted as issues will be closed without a response. We want the 'Issues' section to document the progress of the project, it is not the right place for questions about how to use certain parts of the project.
+If you have general questions, feel free to file them in the 'Issues' section but make sure to add the 'question' tag to it. If you have an issue or a question that you can not discuss in public, do not hesitate to contact the project maintainer directly.
 
 If you want to start working on an issue that you want to file as a pull request, please leave a short notice in the issue to let everybody see that you are working on this and post status updates when appropriate.
 
@@ -25,7 +25,7 @@ If you want to implement a large feature or do other work that results in a lot
 
 ## Commit messages
 
-We think good commit messages are as important to open source projects as a clean code structure. We do look at them very carefully. Please take your time and think about what changes to group in a commit and how to describe the commit.
+We think good commit messages are as important as a clean code structure. We do look at them very carefully. Please take your time and think about what changes to group in a commit and how to describe the commit.
 
 A commit message should describe the changes in a way, that somebody who does not know the related issue or the state as it was before is able to understand the changes. All commit messages should be written in the imperative. This matches nicely with commit messages generated by git (e.g. merge commits) and is way more readable than other styles.