Merge or Cherry-Pick?

[Johannes Sixt]

Am 2/3/2011 6:10, schrieb Dawit A:
> What happens if I tested a bug fix and wanted it to push it upstream
> so that it can receive even wider testing, but it just so happens the
> time to tag the next bug fix release is right around the corner ? The
> original intent is to at least leave the bug fix in the trunk for
> several days to see if it causes any unforeseen regression. It is an
> impossible task for any developer, specially one working on the
> plumbing libraries, to test every possible combination or use case. If
> the push is done into a stable branch, then there is a real
> possibility that users are going to get exposed to unintended
> regressions.

I'll assume you meant to say "push is done into a stable branch *too
early*..." (otherwise, the last sentence in this paragraph is incompatible
with the first part of the paragraph).

You do it this way:

1. You fork off a topic branch from stable, and place your fix there.

2. Compile-test the fix. (Bonus points, if you can test the fix in action
with the stable version.)

3. Merge that topic into master. Compile and test.

4. Publish the merge. Let it cook for a week in master.

5. Looks OK? Good. Merge the topic into the stable branch as well. (The
stable branch might have progressed in the past week, hence, you don't
necessarily fast-forward, but get a real merge.)

6. Merge stable into master and publish both.

However, if you cannot test your fix with the stable version yourself, you
should ask someone to do Step 5, additionally Step 5b "test with stable
version", and Step 6 for you.

Hannes
-- 
"Atomic objects are neither active nor radioactive." --
Programming Languages -- C++, Final Committee Draft (Doc.N3092)