Torque Branching Model

Torque uses Stable Master branching strategy*.

To give a short explanation of how the branches and how we use them:

master should be kept stable at all times. New releases are branched from master, and the development work for those releases happens in other branches that have to pass a series of tests before being allowed to merge into master.

develop is the miscellaneous new development branch. Any fixes not related to a feature are put here; some refactoring and minor features may go in here as well.

feature/* are branches for specific features that are going to go into the release. Performing the development work in separate branches allows us flexibility to easily cut a feature from a release if it isn't ready in time; it also allows us to test separately and make sure that concurrent development doesn't interfere with other features.

X.Y-dev are maintenance branches. Each fix release is branched from these branches: 6.0.2 was branched from 6.0-dev. These branches can have small, well-encapsulated features and fixes placed in them. Refactoring, major features, or other invasive changes must happen either in develop or a feature branch.

X.Y.Z are release branches. These are not changed after the release. Some may wonder why we don't use tags instead of branches, and the reason is that we provide hotfix releases from time to time, and there is no way (that we know of) to create a hotfix release from a tag.

X.Y.Z.hV are hotfix branches. At times, we need to fix a bug for a specific user or kind of user, but we do not wish to make a new release, so we create a branch that is a previous release + one or a few fixes. For example: 6.0.2.h1 would be branched from 6.0.2 and just have a fix or two checked in. These are also not changed after being released.

*The linked page describes the theory behind what we're doing; we have tailored it somewhat for our needs, but this is a good description of the overall process.