From f309cf79bbb032a0686b7d04feb8fec18e600a84 Mon Sep 17 00:00:00 2001 From: Kitzunu <24550914+Kitzunu@users.noreply.github.com> Date: Sat, 12 Jun 2021 14:50:58 +0200 Subject: 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 --- docs/Project-Versioning.md | 49 ---------------------------------------------- 1 file changed, 49 deletions(-) delete mode 100644 docs/Project-Versioning.md (limited to 'docs/Project-Versioning.md') diff --git a/docs/Project-Versioning.md b/docs/Project-Versioning.md deleted file mode 100644 index 21ae4d3..0000000 --- a/docs/Project-Versioning.md +++ /dev/null @@ -1,49 +0,0 @@ - -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 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 | ~ | ~| -- cgit