\documentclass{article}
\usepackage{ulem}
\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 semantic versioning\footnote{http://semver.org/}, 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.}
\begin{itemize}
\item{Adding features or extending APIs will bump the minor version, Horde 4.0 becomes Horde 4.1 etc.}
\end{itemize}
\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 Doc/Dev/ConversionH4\footnote{http://example.com/index.php?page=Doc/Dev/ConversionH4} and Doc/Dev/ConversionH5\footnote{http://example.com/index.php?page=Doc/Dev/ConversionH5}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 Doc/Dev/Branches\footnote{http://example.com/index.php?page=Doc/Dev/Branches} for an explanation of the branches used to prepare releases.

\end{document}
