Commit fdd90e2e authored by bmortier's avatar bmortier

Merge branch '1-adding-release-policies' into 'master'

Adding FusionDirectory Release policy documentation

Closes #1

See merge request !5
parents f4af4497 e1613f8f
......@@ -21,6 +21,7 @@ Contents:
.. include:: globals.rst
FusionDirectory Life Cycle
A maintained version is a **major** version for which we release **minor** bug fix releases and communicate about security vulnerabilities.
Our general support policy is to maintain major releases until **3 months** after the next major version is released to give some time for upgrading.
We also provide a more conservative life-cycle through **ESR** versions.
The **ESR** tag is given to a major release once it has been thoroughly tested and proven reliable on real production systems.
**ESR** versions are maintained until **6 months** after the next **ESR** version is announced, allowing less frequent major upgrades,
and a larger time-frame for switching between them.
Release Policy
This section explain the release cycle and where contributions, fixes will be merged
.. toctree::
:maxdepth: 2
FusionDirectory Version policy
FusionDirectory can have 3 digits at maximum in a version : **X.Y.Z**
**Z** version increments (X.Y.Z1 –> X.Y.Z2, for example 1.2.1 to 1.2.2) are minor bug fix only releases.
**Y** or **X** version increments are major releases (X.Y1.Z -> X.Y2.Z, for exemple 1.1 to 1.2) are major releases.
Major Release
* Can contain any type of bugfix, new features and code refactor.
* Can remove attributes or objectclasses from the schema only if they were declared OBSOLETE in the previous major release.
* Can put **OBSOLETE** attributes and classes which are no longer used by the code.
* Two 2 major releases are needed before removing OBSOLETE attributes and objectClass.
* Can provide migration scripts in fusiondirectory-setup if needed for those, and/or migration instructions in the documentation.
* Have to provide migration instruction from previous major release.
Minor release
Minor release are small releases containing only bugfix to the last major release. It should be numbered with 3 digits.
Minor release **cannot** contain :
* Schema changes
* New features
* Code refactor
* Poorly tested code
* Changes which may break existing plugins or themes for previous release (or scripts based on the webservice)
Minor release contain :
* bugfix : should fix a bug observed in a previous release, something which did not work as intended.
Exceptions can be made :
* New feature can be included if it does not require any schema change and does not interfere with existing features
* Code refactor can be included if it leads to a significant performance gain and is thoroughly tested
* New plugin may be added if it does not require schema change (but it can add new schemas as this is non-intrusive)
Minor release must be released as soon as possible when :
* Security breach is found in the last stable release
* Regression (a bug which was not there in previous releases) is found in the last stable release
* Major bug is found in the last stable release
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment