This project is read-only.

Branch Development

Apr 10, 2013 at 12:55 AM
OK, I kind of feel foolish asking this question. I have been randomized by several articles which contradict my background experience and knowledge in this area. But this is a different kind of a project than what I am used to in the enterprise, so I am prepared to believe that others have varying opinions about this for an open source project. So, I would like to reach some concensus as the project moves forward.

Development with Branches - in this project.

We use GIT, we use personal Forks, and we currently use branches for different released versions of the code. (i.e. 'master' - being the main trunk and representative of the project moving forward, a snapshot of the release, and the next major release in development.)

The intention to date has been to develop major releases on seperate branches (i.e. like and merge back into 'master' when that code is released, effectively freezing the release branch.

But many believe in developing the current/next release on the main trunk, and merging to the release branch as the release is built up and then freezing it later. Slightly different appraoch, probably technically no difference to GIT, but nonetheless this is a change in the work flow of the community.

So, what is best and why?
  1. Developing on a version branch (i.e., and merging to 'master' trunk at release time.
  2. Developing on 'master' trunk and merging to release branch, up to the release time.
Either way we need to be clear on this workflow in the community.

So, over to you.
Your thoughts and rationale for either way, or another?
Apr 10, 2013 at 2:50 PM
I vote for #2: developing in Master and merging to a release branch at release time. The team is small now and there is little need for a development branch as a quality gateway to Master. Also, if we have a development branch then Master will have no activity until we get close to a release, and then it will just be a quick pass-through to a release branch. Developing on Master is just simpler to manage and has no risks at this point. Maybe if the team gets larger and different groups need to work in isolation it will make sense, but given the small team size now I don't think we need a development branch.
Apr 10, 2013 at 3:09 PM

It simplifies applying urgent bug fixes to existing releases, since you just fix them on master and then cherry pick the commit to merge with the release branch
So +1 to dev in master

/kzu from mobile

Apr 10, 2013 at 8:50 PM
Thanks guys,

Happy with all that, it does make life simpler to dev on master, and document for new contributors of course. +1
I might suggest that for this release (which is now imminent) we just keep committing to the branch, and merge to master when ready - as we have been doing to this point of this release. Then from that point, just continue on master, cherry pick and and make version branches when necessary.