Feature Process

This page describes some guidelines around developing fixes and features.

There are two main persistent branches in the repository:

• develop --- this branch points at the latest code that has been landed and will be in the next release
• master --- this branch always points at the latest release

The only way the master branch gets updated is by cutting a new release via the Release Process.

The only way the develop branch gets updated is by merging a feature branch that has been accepted via the process described below (excepting some sync updates made while cutting a release).

To begin developing a change:

1. make a local clone of the repository (or update your develop branch to the latest commit, if you already have a clone)
2. create a new local branch (based on develop) to work on (you can have more than one if you need to work on multiple changes concurrently)
3. make changes and commits as necessary to your local branch (NOTE: when writing commit messages, follow the commit message format; the following guidelines are also desirable: https://chris.beams.io/posts/git-commit/)
4. when you are ready, push your branch to the repository (use the main repo if you are a contributor, otherwise you will need to push to your own fork)
5. create a github pull request to the develop branch (note that, since master is the default branch, you will need to change the branch the pull request targets to do this)
6. (optional) add at least one contributor as a reviewer, if you don't then someone will add a reviewer for you
7. if the reviewer has comments or requests changes, address those by adding new commits to your local branch and pushing them to github (note that when you push these changes to the branch they will appear on the pull request automatically)
8. once at least one reviewer has approved, and there are no reviewers still requesting changes the pull request is eligible for merging by any contributor
9. it is customary to check with the author of the pull request that they are ready for it to be merged before continuing
10. ensure a CLA has been signed by the author of the changes, if one is required
11. merge the pull request using the "Squash and merge" button, and make sure that the title used for the merge is descriptive as it is the message that will appear against the change in the change log. Also, make sure that the body of the commit message is cleaned up to only contain relevant details to the final feature (remove the commit summaries for transitory commits that are created by default)