=====================
 Horde Release Cycle
=====================

This is an explanation of the Horde release model and the project's release rules.

* We will stick to `semantic versioning`_, this means:

  * APIs* keep backward compatible within the same major versions. If we have to break backward compatibility, Horde 4 becomes Horde 5 etc.

    * Adding features or extending APIs will bump the minor version, Horde 4.0 becomes Horde 4.1 etc.

* New versions will be released every half a year. Whether these are going to be major or minor version releases (or even just bug fix releases) depends on whether the changes since the last release broke BC or not.

  * Intermediate releases can be be done for security fixes or bug fixes.

* We will have sychronized releases of all application and framework components. If it's going to be a minor version release, only the modules that actually had any changes will be released. For major versions, all modules will be relased.

* Breaking backward compatibility will be documented, so that custom applications can be updated easily. See `Doc/Dev/ConversionH4`_ and `Doc/Dev/ConversionH5`_for an example.

* The most recent two major versions will be maintained with security fixes, i.e. for at least 12 months.

*APIs in this context mean PHP APIs of framework components, external PHP APIs of applications, and external Horde RPC APIs.

.. _`semantic versioning`: http://semver.org/
.. _`Doc/Dev/ConversionH4`: https://wiki.horde.org/Doc/Dev/ConversionH4?referrer=Doc%2FDev%2FReleaseCycle
.. _`Doc/Dev/ConversionH5`: https://wiki.horde.org/Doc/Dev/ConversionH5?referrer=Doc%2FDev%2FReleaseCycle

See also `Doc/Dev/Branches`_ for an explanation of the branches used to prepare releases.

.. _`Doc/Dev/Branches`: https://wiki.horde.org/Doc/Dev/Branches?referrer=Doc%2FDev%2FReleaseCycle