Our Development Model

Our model is a somewhat scaled-down version of how the Git project itself is run. We have two main branches

• master: release quality

• dev: integration branch for commits expected to go to master

In addition, we have:

• feature branches not yet ready for integration testing, starting with the two character initials of the author, e.g., db/1368 for Dave Brondsema's work on bug [#1368] or wo/contributing for Wolf's work on the CONTRIBUTING doc

'master' and 'dev' are stable; they will never be rewound or rebased. Feature branches are typically cut from 'dev', and usually rebased to 'dev' just before they are merged there. In the meantime they may be rebased or rewound as necessary. Being on 'dev' is not a guarantee that a commit will make it to master. Anything that turns out to not actually be ready will be reverted.

'dev' will always contain 'master'. Emergency fixes may go directly to 'master' which would then immediately be merged down into 'dev'.

As we get more contributors and start having "patch-churn", we will re-evaluate a three-branch model, like Git. The third branch would be 'pu' (for "proposed update").

We expect that people deploying the code will deploy from 'master' or from a release tag. We expect that people experimenting with the code will deploy from 'dev' or from their own feature branches or integration branches cut from 'dev'.