Page History

The policy on branch creation and workflow, which is central to the process of creating, enhancing, and maintaining DM software, is described below. 

Branches

There are two main integration branches, master and next, a group of maintenance branches release/xxx, and the "ticket" (also known as "topic" or "feature" branches), named tickets/xxx. 

• master is the integration branch for the current development cycle, and is the branch off of which Data Productions are run. After a first successful (released) production, master is branched off to release/xxx (where xxx is the version or a descriptive tag: DM-xxx)
• next is the integration branch where new features are supposed to land after the current development cycle (or that are driven by other projects). Once the current development cycle finishes, next will be merged into master.
• New features or fixes are developed on ticket branches, which must correspond to JIRA tickets, and should be branched off:
  • release/xxx, if the the feature is a fix to a bug in already released software
  • master if the feature is related to the current development cycle, and
  • next otherwise.

Branching Workflow

At the at the end of a cycle of development, or at the beginning of a new cycle, we:

• branch release/xxx off of master, after the end of the cycle (or data production). Only bug-fixes and minor feature additions are allowed on this branch, to ensure long-term API stability for external users (e.g., the Camera Team).
• merge next to master.
• re-branch next, for new non-critical work.

Any bugfixes that happen on release/xxx should immediately get merged and/or cherry-picked to master. master may infrequently get merged to next, if features implemented on master become needed by the users of next (but not otherwise). 

(Historical note: this page was migrated and lightly edited from a Trac Page on this topic.)