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
