Diff for Doc/Dev/Branches between 1 and 2

+ Branch management

(First draft, already superceded)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.

We will actively maintain 3 development branches in Git:

*++ Main development for the next release happens in the **master** branch.
  * Only when the release process starts, we will branch off **master**, so that we can stabilize the code for the next release, while still going forward with development in **master**.
  * Major, especially BC breaking changes will be done in **topic branches**, to not have the **master** branch polluted with unstable code when the next release cycle arrives.
* The most recent two **major version branches** will be maintained with security fixes.branches

IfThere 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//:

<code>
$ git checkout develop
$ git merge master
$ git push
</code>

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//:

<code>
$ git checkout develop
$ git checkout -b newfeature
</code>

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:

<code>
$ git checkout develop
$ git merge newfeature
$ git branch -d newfeature
</code>

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:

<code>
$ git checkout master
$ git branch FRAMEWORK_4_0
$ git merge develop
</code>

Since we always ((Doc/Dev/ReleaseCycle|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.

If for example we already had 4.0, 5.0 andand 5.1 releases and are now working on thethe 6.0 release, we would maintain FRAMEWORK_4_0, FRAMEWORK_5_1//develop//, //master// and master//FRAMEWORK_5_1// branches. Once 6.0

++ Tools

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