Branching Strategy

Our main development happens in the develop branch. So when you create a feature branch, you should branch off the develop branch. master branch is only updated with new releases (the only exception to this rule might be hotfixes).

Whenever a feature is considered complete and tested enough, it should be merged back to develop. Ideally, feature branches should live at most two months; the shorter the better; so that they don't diverge too far from develop branch and thus merging remains simple.

When preparing for a new release:

• Merge remaining feature branches that should go into the release into develop
• Make sure iAnalyse builds everywhere (e.g. via CTest/Dash), and that tests run through.
• Create a release branch from latest develop; either including a version number (e.g. release-2016.06), or just use release. The former case has the advantage that we can keep the release branch in the end (and apply fixes to it easily, if required), the latter has the advantage of a clean repository, less cluttered with many branches.
• Test the executables from the branch extensively
• Fix bugs directly in the release branch
• In case release preparation takes more than a few days, or when there is lot of changes in the develop branch in the meantime, occasionally merge the fixes from the release branch back to develop

When releasing:

• Merge the release branch to master
• Merge master or the release branch (if you haven't done anything wrong, these should now be the same) to develop
• Make sure all builds and tests in the preparation have worked fine
• Create a tag on master; needs to contain:
  • The version number (typically the year and month of the release, e.g. "2016.06") as name
  • The versions of the toolkits that were in use for testing the build (Qt, vtk, itk, ...) in the comments
• Push merged master along with tags to github.
• In case you used release as release branch name, delete the branch