We are using the semantic versioning standard:
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.
PHASE 2: Content fixes: At start of this phase we will publish first
create a branch for it
export base db with updates included, but we will keep files in sql/updates to allow you easily upgrading from a previous release
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
|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||~|