Our git branching model and release strategy
We use the TwGit flow by Twenga to manage our software releases. What this means is that the repository will always have a branch named
stable and this will contain the very latest official release. Official releases will also be tagged using Semantic Versioning.
Upcoming releases that we're working on will have their own release branch that will live until the release has been finalized and merged into
stable. The naming convention for these branches is
x.x.x is the proposed release version number.
Individual changes are all made in their own feature branches that are merged into the release branch when they're ready to be tested with the upcoming release. The naming convention for these branches is
JIRA-XXX is the JIRA issue number that is being worked on.
Whenever we push changes to the GitHub repository, we have Travis CI run our test suite (the test results are posted to our downloads site). In addition, we also have Travis create a packaged zip file of the system when the branch being pushed is a release branch, or when we push a tag.
What this means for you
For the most part, you don't really have to worry about this branching model. If you're contributing code changes, our guide to contributing changes, should give you all you need to know.
That said, if you are pulling down the code from Git, and want to be on the latest version in development, be sure to checkout whatever release branch exists at the time. If you want the official releases, you can stick with the stable branch.