On 27/03/2012 15:28, Vladimir Vuksan wrote: > In my mind it doesn't. It just adds the job of merging down the line. I > prefer to work on the trunk since that forces you to actually make > things work and not defer changes since you have them sitting on a > branch. I understand there are pros and cons to both approaches. I just > don't see that as a problem that needs to be solved at this time. I > would prefer we spent our time of fixing/improving things instead of > process.
I am only talking about release branches, not feature branches A feature branch is something I create (e.g. to overhaul the autotools stuff) and I am responsible for merging that in to master (trunk) later when I think it is ready. Thanks to the wonders of git, people are free to do that if and when they please. In contrast, a release branch basically draws a line underneath a minor release (e.g. 3.3 series). It never has to be merged back to master. Typically, bug fixes are done on master, and then the bug fix is selectively merged into the release branch, but only if it meets certain criteria: - only if the bug fix relates to the release - only if the bug is over some threshold of severity Example timeline: new feature A branch 3.3 release 3.3.0 new feature B branch 3.4 release 3.4.0 find and fix bug in B (b1) release 3.4.1 find and fix bug in A (b2) release 3.3.1 and 3.4.2 In the above example, notice that nobody has to bother merging the fix for (b1) back into the release/3.3 branch ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers