Re: «Bug fixes should always be committed first to the oldest branch they apply to.» Huh?

[Kevin Bullock]

On 6 Jul 2011, at 12:44 PM, Tony Mechelynck wrote:

> http://mercurial.selenic.com/wiki/StandardBranching#Where_to_apply_fixes
> 
> <quote>
> 5.1. Where to apply fixes
> 
> Bug fixes should always be committed first to the earliest maintained release branch they apply to. This will allow you to get maximum advantage out of Mercurial's merge intelligence.
> </quote>
> 
> 
> So,let's say I have the following branches (imaginary case):
> 
> default: the branch for active development, pre-alpha or alpha for everything which hasn't yet been branched off
> 
> version7: a branch for future version 7, currently undergoing beta-testing
> 
> version6: a branch for version 6, the current public release
> 
> version5: a branch for the former release, still supported with security and stability updates
> 
> Versions 4 and earlier aren't supported anymore.
> 
> When a bug is found which affects all supported versions, I would expect to fix it first on default, do whatever tests I can on the fix (does it compile? does it pass whatever more-or-less standardized tests "make test" in its Makefile runs on it?), (reverse the patch if the tests fail, then look for a better fix) and if they pass, port the fix first to the branch still in beta (version7) so that beta-testers can check it some more, maybe live-testing the patched product for some time in various environments,

You would really want to test an important bugfix in a _beta_ release, which is assumed to contain lots of bugs that might interact in new and surprising ways with the bugfix? Good engineering would dictate that you fix the bug in as isolated and known-stable an environment as possible anyway; the longer a release is in the wild, the (hopefully!) more stable it is.

Presumably if you're fixing a bug on a release branch, it's because the bug was _found_ in that release (or possibly a newer release, and then verified to exist in the older release too). So the rough process would be:

1. Bug is discovered in (let's say) version6.
2. Bug is investigated, and discovered to also exist in version5.
3. Bug is fixed on the version5 branch, and the fix is thoroughly tested (perhaps even with trial builds given to customers experiencing the bug so they can verify the fix).
4. Fix is merged to version6, and again tested thoroughly.
5. Fix is merged to version7, and tested as a normal part of the beta process.
6. Fix is merged to default. By this time you should also have a test case that thoroughly tests the bug to prevent future regressions.

In a usually-pretty-workable modification of this process, you could fix the bug on default, and then transplant (backport) the bugfix onto release5 for testing. Then you can merge that fix forward onto version6 and version7.

> before the fix reaches (and so as to avoid possible crashing, breaking, etc. of) the current stable branch, and then to backport the fix to the former branch if the bug is deemed severe enough and the branch hasn't died by then. You're saying I should do the opposite,

Yes.

> and in particular release the fix to all public branches before testing it in any serious way?

No. It should be perfectly possible to set up a sufficient testing process for releasing bugfixes to maintenance branches. I don't see how testing a bugfix on a newer branch can ensure that the fix works on a maintenance branch anyway. You have to test it somehow _on the branch you're going to release from_.

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock