This information is aged. Post git split, horde doesn't use a develop branch anymore. Features get developed in feature branches or most times forks and integrated into the master branch via pull requests. I have not checked for other outdated info.

===================
 Branch management
===================

We follow a branching model that is a very simplified version of http://nvie.com/posts/a-successful-git-branching-model/. The main difference is that we do bug fixing and make releases from the *master* branch, and only use release branches for older, still maintained versions. It is suggested to read this post first, to get an larger view on the ideas behind our branching model.

---------------
 Main branches
---------------

There are two main branches, *master* and *develop*.

- *master* is the branch for adding bug fixes. This is the code that will become the next bug fix release.
- *develop* is the branch for adding new features. This is the code that will become the next major or minor release.

*develop* has been branched off from *master* at one point, and from time to time, bug fixes that have been applied to *master* are merged back into *develop*:

::

 $ git checkout develop
 $ git merge master
 $ git push

It is suggested to do that merging and pushing in a single, separate action, so that "real" work on the *develop* branch isn't get lost in the large commit messages of the merging.

----------------
 Topic branches
----------------

Even though *develop* is the branch for new development and adding features, larger features should be developed in a topic branch that is branched off *develop*:

::

 $ git checkout develop
 $ git checkout -b newfeature

This is to avoid breaking code in *develop*. This is important, because *develop* is used for the next minor release, which will be created at a set date. To avoid having to revert commits if *develop* is unstable when the next release is near, such development must be done in topic branches, that can be merged back to develop, once they stabilized:

::

 $ git checkout develop
 $ git merge newfeature
 $ git branch -d newfeature

These topic branches can be private, or public if other should participate in development or testing. For creating public branches, see http://www.horde.org/development/git#creating-managing-remote-branches.

Topic branches are especially important when developing code that breaks backward compatibility, if it has **not** been decided yet whether the next release will be a major or minor release.

------------------
 Release branches
------------------

Release branches are maintenance branches for older releases. Once the release process for a new minor/major version is starting, the current version's code is branched off *master* into a release branch, before the current *develop* branch is merged back into *master* for the new version:

::

 $ git checkout master
 $ git branch FRAMEWORK_4_0
 $ git merge develop

Since we always `maintain the two most recent minor versions`_ with security fixes, there will always be 3 active branches (topic branches aside) at the same time. *master*, *develop*, and the release branch for the last minor version.

.. _`maintain the two most recent minor versions`: https://wiki.horde.org/Doc/Dev/ReleaseCycle?referrer=Doc%2FDev%2FBranches

If for example we already had 4.0, 5.0 and 5.1 releases and are now working on the 6.0 release, we would maintain *develop*, *master* and *FRAMEWORK_5_1* branches.

-------
 Tools
-------

[gitflow https://github.com/nvie/gitflow] is a tool for managing the branching model of Vincent (nvie). If necessary, we might be able to fork and adapt it to our simpler needs.