I suggest we adopt the gitflow model for branching as described in [1] and [2]. Following an established and consistent pattern for branching makes it easier for new users and devs to contribute.
Here are the main gitflow concepts: 1) The master branch is reserved for production-ready code, aka releases. No changes are made directly on the master branch. 2) The develop branch is the development mainline. Ongoing work shows up here first. 3) Feature branches may be used to isolate interim work and will merge back to develop. 4) Release branches are created to allow a stabilization period for a release while not impacting ongoing work on develop. Once a release is stabilized the release branch is merged to master and develop. 5) Maintenance branches are created after a release (off master) to support ongoing hot fixes and patches as needed. This diverges slightly from the “hotfix” model in the original gitlfow idea but works better for releases with a longer life span. Branch naming: - master - develop - release/vVERSION - maint/vVERSION where VERSION is semantic version name [3]. Actions needed: 1) Create the develop branch off of master. 2) Run nightly builds from the develop branch. 3) Set the default branch for the repo to develop (is this possible with the ASF git repo?). 4) Create a wiki page to codify the model and naming conventions. Thoughts? Anthony [1] http://nvie.com/posts/a-successful-git-branching-model/ <http://nvie.com/posts/a-successful-git-branching-model/> [2] https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow> [3] http://semver.org <http://semver.org/>
