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

[Matthieu Moy]

Tony Mechelynck <antoine.mechelynck at gmail.com> writes:

> On 06/07/11 19:59, Matthieu Moy wrote:
>> Tony Mechelynck<antoine.mechelynck at gmail.com>  writes:
>>
>>> <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>
>>
>>> You're
>>> saying I should do the opposite, and in particular release the fix to
>>> all public branches before testing it in any serious way?
>>
>> The text you're quoting doesn't mention any release. It mentions
>> "release branches". The order in which you do commits and merge doesn't
>> have to be the one in which you do public releases.
>
> Well, in the example I gave, the still-supported release branch
> earliest split off the trunk gave rise to beta releases 5b1, 5b2, 5b3
> and public releases 5.0, 5.1, etc., 5.11. The one next split off was
> 6b1, 6b2, 6b3, 6b4, 6.0, 6.1, 6.2 and 6.3. Off the version7 branch
> there has been beta release 7b1; its current nightly builds are called
> 7b2pre which doesn't correspond to anyting frozen. There are other
> nightly builds (8a1pre) for developers and automated tests off the
> default branch. Isn't version5 the "earliest maintained release
> branch"?

You can enumerate as many version number as you whish, that doesn't
force you to release code in the same order as you commited it.

Anyway, it seems you're not really looking for help here, just
complaining, so end of discussion on my side.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/