On Sat, Aug 11, 2012 at 8:03 PM, Stefan Schulte <[email protected]> wrote: > How does the situation now looks for someone who wants to merge code? > Let's say there is a request to pull ticket/master/foo into master. If I > get it right I would first merge the code into the master branch and if > I don't do anything afterwards the new code will be present in the next > major release (so when 3.1.x is created I guess) and not earlier. >
What we have been doing is immediately trying to figure out which branches the change needs to be on and rebasing to that and then merging up. For example, a PR for a bug that is found in 2.7.18 is submitted against master. We determine that the fix is good for 2.7.x (because of low impact on other things) and so apply the PR to a topic branch of 2.7.x and merge it in, then we merge up through 3.x and master. You do touch on something that I've been wondering about. We somehow have ended up with a 3.x branch, which would mean that master is really the 4.x branch. I don't see any point on us trying to work on 4.x when there isn't even a 3.x release yet. Would anyone be opposed to us getting rid of the 3.x branch? I think the flow would then be that topics merge onto master. At a release point we would merge master onto a "3-stable" (or something, I'm not sure about the name, 2.7.x is essentially 2.7-stable). Points along "3-stable" would be tagged as 3.0.0rc1, 3.0.0, 3.0.1rc1, etc.This is essentially the stable/development strategy for branching that gets talked about, I believe. > If the change needs to be backported to older branches how does this > work? If I checkout 2.7.x and cherry-pick commits from the master > branch the history of 2.7.x does not say which commit belongs to which > old feature branch right (no merge commits)? Or would I copy the branch > ticket/master/foo as ticket/2.7.x/foo and use git rebase with --onto > 2.7.x and then merge ticket/2.7.x/foo into 2.7.x? > I think your second one is what would be best. That would keep a merge commit to more easily track the history. Of course, if it is just one or two commits that are being cherry-picked from another branch, then I see no need for that and I think it is perfectly reasonable to go ahead without the topic branch and merge commit. > -Stefan > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
