On Fri, May 1, 2015 at 7:07 AM, jan i <[email protected]> wrote: > On 1 May 2015 at 15:53, Anthony Baker <[email protected]> wrote: > > > 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. > > > I would make an even tighter definition here. > > Master is merged solely from develop, and only by the "release manager". > Merges can only be done, when build is successful on all supported > platforms, and > the tests on all supported platforms have passed. > > > > > 2) The develop branch is the development mainline. Ongoing work shows up > > here first. > > > +1 > > > > > 3) Feature branches may be used to isolate interim work and will merge > > back to develop. > > > Public feature branches should only be used, when multiple people work on a > feature. A feature branch is started after the intention is made clear on > dev@ > > I would like to propose a convention that the public feature branches have a JIRA issue number as part of their name to make it easy to tie the branch to the work taking place on it.
> > > > > 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. > > > This is the purpose of master, I would not make extra release branches, > however this is close to being religious. If release branches are made they > should solely relate to master, NOT to develop. > > Instead of a branch, which is a lot of overhead, I would just use the GIT > id of master, to identify the original release. > > > > > > 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. > > > +1, but it should be avoided, to keep the logistic (non-productive) work > volume low, try to avoid making a hotfix for older releases. > > > > 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. > > > and e.g. weekly builds on master. Alternatively, whenever master is updated > run a build. > > 3) Set the default branch for the repo to develop (is this possible with > > the ASF git repo?). > > > yes > > > 4) Create a wiki page to codify the model and naming conventions. > > > +1 > > > > > Thoughts? > > > Please see my thought, not as an active developer, but as a mentor with > experience from other projects. > > +1. > > > > > Anthony > > > nice suggestion. > > rgds > jan i. > > > > > > > [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/> > > > > >
