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/ConversionH5for 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.

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