\documentclass{article}
\usepackage{ulem}
\usepackage{graphicx}
\usepackage{hyperref}
\pagestyle{headings}
\begin{document}
\part{Horde Release Cycle}
This is an explanation of the Horde release model and the project's release rules.

\begin{itemize}
\item We will stick to <a href="http://semver.org/">semantic versioning</a>, this means:
\begin{itemize}
\item APIs* keep backward compatible within the same major versions. If we have to break backward compatibility, Horde 4 becomes Horde 5 etc.


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


\end{itemize}

\item 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.
\begin{itemize}
\item Intermediate releases can be be done for security fixes or bug fixes.


\end{itemize}

\item 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.


\item Breaking backward compatibility will be documented, so that custom applications can be updated easily. See <a href="https://wiki.horde.org/Doc/Dev/ConversionH4">Doc/Dev/ConversionH4</a> and <a href="https://wiki.horde.org/Doc/Dev/ConversionH5">Doc/Dev/ConversionH5</a>for an example.


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


\end{itemize}
*APIs in this context mean PHP APIs of framework components, external PHP APIs of applications, and external Horde RPC APIs.

See also <a href="https://wiki.horde.org/Doc/Dev/Branches">Doc/Dev/Branches</a> for an explanation of the branches used to prepare releases.

\end{document}