Thanks for commenting jan. To me the value of the release branch is allowing uninterrupted ongoing work on the develop branch while isolating the work to stabilize the code in preparation for a release. I would hesitate to merge directly from develop to master until we had proven stability which usually requires a settling out period. But like you say this is a philosophical thing and I am fine with which ever approach we decide upon.
Anthony > On May 1, 2015, at 7:07 AM, jan i <j...@apache.org> wrote: > > On 1 May 2015 at 15:53, Anthony Baker <aba...@pivotal.io> 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@ > > >> >> 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. > > >> >> 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/> >> >>
