diff --git a/assets/merge_into_dev.dia b/assets/merge_into_dev.dia
new file mode 100644
index 0000000..5bccbc0
Binary files /dev/null and b/assets/merge_into_dev.dia differ
diff --git a/assets/release_branch.dia b/assets/release_branch.dia
new file mode 100644
index 0000000..149a9d4
Binary files /dev/null and b/assets/release_branch.dia differ
diff --git a/docs/05_releasing.md b/docs/05_releasing.md
new file mode 100644
index 0000000..3807f10
--- /dev/null
+++ b/docs/05_releasing.md
@@ -0,0 +1,51 @@
+# Releasing a new NewPipe version
+
+This site is ment for those who want to maintain NewPipe, or just want to know how releasing work.
+
+![one does not simply push to master](img/onedoes.jpg)
+
+## Difference between regular and hotfix release
+
+NewPipe is a web crawler. That means it does not use a web API, but instead tries to scrape the data from the website,
+this however has the disadvantage of the app to brake instantly when Youtube changes something.
+We can not know when this happen therefore we need to be prepared when it happens, and at lease reduce our downtime as
+god as possible. Our whole release cycle is therefore designed around this issue.
+
+So there is a difference between a release that is meant to introduce new features or fix minor bugs,
+and a version that fixes an issue that occurred because Youtube (or some other service) suddenly changed their website (mostly call this a shutdown).
+Lets first have a look how a regular release work, and then how the hotfix release work.
+
+## Regular releases
+
+Regular releases are normal releases like they are done like in any other app. Releases are always stored on __master__ branch. By means the latest commit on
+__master__ is always equal to the current releases. No development is done on master. This ensures that we always have one
+branch with a stable/releasable version.
+
+### Feature branching
+For development the __dev__ branch is used. Pushing to __dev__ directly however is also not allowed since QA and testing should be done before pushing to __dev__.
+This ensures that also the dev version works as good a possible.
+So in order to change something on the app one may want to __fork__ the dev branch and develop the changes in his own branch (this is called feature branching).
+
+![feature_branching](img/release_branch.svg)
+
+### Merching features/bugfixes
+
+After being done with the feature one should open up a __Pull Reuqest__ to the dev branch here a maintainer can do __Code review__ and __Quality Assurance (QA)__.
+If you are a maintainer please take care about the code architecture so corrosion or code shifting can be prevented. Please also preface core quality over functionality.
+So in short: cool function but bad code -> no merge. We should focus on leaving the code as clean as possible.
+
+![merge_feature_into_dev](img/merge_into_dev.svg)
+
+At best you as a maintainer should build the app and put the signed apk into the description of that new Pullrequest. This way other people can test the feature/bugfix and therefore help with QA.
+
+### Creating a new release
+
+### Releasing
+
+## Hotfix releases
+
+![this_is_fine](img/could_not_decrypt.png)
+
+### Fix branch
+
+### Releasing
diff --git a/docs/05_documentation.md b/docs/06_documentation.md
similarity index 100%
rename from docs/05_documentation.md
rename to docs/06_documentation.md
diff --git a/docs/img/could_not_decrypt.png b/docs/img/could_not_decrypt.png
new file mode 100644
index 0000000..3321590
Binary files /dev/null and b/docs/img/could_not_decrypt.png differ
diff --git a/docs/img/merge_into_dev.svg b/docs/img/merge_into_dev.svg
new file mode 100644
index 0000000..f837f1b
--- /dev/null
+++ b/docs/img/merge_into_dev.svg
@@ -0,0 +1,210 @@
+
+
diff --git a/docs/img/onedoes.jpg b/docs/img/onedoes.jpg
new file mode 100644
index 0000000..da7f658
Binary files /dev/null and b/docs/img/onedoes.jpg differ
diff --git a/docs/img/release_branch.svg b/docs/img/release_branch.svg
new file mode 100644
index 0000000..ba3c833
--- /dev/null
+++ b/docs/img/release_branch.svg
@@ -0,0 +1,127 @@
+
+