chore: file naming standard (#517)

* A

* file naming standard
Fixes #491

* Revert "A"

This reverts commit 1c225fed753554098069597a2bbcbe08213b76a1.

* rename

* Revert "rename"

This reverts commit 65fd916faf8530ce258cc2b475c93971468680fe.

* Revert "file naming standard"

This reverts commit 6ca5a703a9e9d59f9c773029e4c04bfd012b6abb.

* bye

* Hi

* Create the-staging-branch.md

* 1

* Delete how-to-create-a-PR.md

* Create how-to-create-a-pr.md

* werafgt

* Update the-modular-structure.md

* wef

1 files changed, 54 insertions, 0 deletions

diff --git a/docs/project-versioning.md b/docs/project-versioning.md
new file mode 100644
index 0000000..e931514
--- /dev/null
+++ b/docs/project-versioning.md
@@ -0,0 +1,54 @@
+---
+redirect_from: "/Project-Versioning"
+---
+
+# Project Versioning
+
+We are using the semantic versioning standard:
+
+http://semver.org/spec/v2.0.0.html
+
+For instance, we can have: **1.5.1** that corresponds to: **MAJOR.MINOR.PATCH**
+
+More in depth:
+
+**MAJOR** version when you make incompatible API / DB structure changes
+
+**MINOR** version when you add functionality in a backwards-compatible manner
+
+**PATCH** version when you make backwards-compatible bug fixes.
+
+Additional labels for branches ( such as -rc , -dev etc. ) are available as extensions to the MAJOR.MINOR.PATCH format.
+
+* **PHASE 1: Developing Phase**: During the developing phase, we will use the master branch where we can freely make changes to API, DB and all things that could break compatibility with old revisions. 
+At the beginning of each development phase, we will clean the sql/updates folders archiving old SQLs.
+
+  N.B. 
+  * Some big jobs, such as rewriting/implementing features, could be not ready for next revision and eventually they will be planned for a future one, so they will be kept in dedicated branches instead of master. 
+  * Using master branch you will have immediate access to new awesome features, but you must take care since some commits can break stability in some rare cases.
+
+* **PHASE 2: Content fixes**: At start of this phase we will publish first <stable> release ( x.0.0 ) and we will:
+
+  1) create a branch for it
+
+  2) export base db with updates included, but we will keep files in sql/updates to allow you easily upgrading from a previous release 
+
+  3) create a downloadable github release and a dedicated wiki page for documentation.
+
+  During this phase we will continue to fix mechanics and contents without break compatibility with API, DB etc.
+
+
+* **PHASE 3: Only Stability and security fixes**: In this phase we will stop to import mechanic / content fix and we will offer support to only security and stability issues. For example: if a function generates a crash for a null pointer, we will fix it.
+
+  We could eventually extends this phase if requested by many people.
+
+* **PHASE 4: End of Life ( EOL )**: We will archive that release keeping documentation and branch ofc. You can continue to use/download it, but we won't offer any official support of any kind
+
+## List of releases
+
+| version/branch | codename  | description | current state | release data | end of support|
+|     --         |    --     |      --     |           --  |       --     |      --       |
+|     0.x        |  Sunwell|  small reworks for sunwell  |EOL|      2016 Q3 |      2017  Q1 |
+|     1.x        |  Mimiron | first version to introduce the module system | EOL|     2017 Q1 |      2019  Q1 |
+|     2.x        |  Gunship | Integrated CI/CD and tons of fixes  | Security & Stability   |     2019 Q1 |      ~ |
+|     master (3.x)        |  ~ | ~ | developing |     ~ |      ~|