Linus Arver [off-list ref] writes:
quoted
* An very old but still severe bug in tagged versions would want to
be fixed ideally not on top of 'maint' but on top of the latest
tagged version in the same maintenance track. E.g. if the commit
X introduced the bug, you may ask "git describe --contains X" the
oldest version the commit appears in, say "v2.30.0-rc2-gXXXXXX".
Then you would run "git checkout -b fix v2.30.9" to start the
branch to fix it.
In this example, are we using v2.30.9 as a starting point, not v2.30.0
because v2.30.9 is the latest tagged version that is in 'maint'?
Yes, the example assumes that the last maintenance release for
v2.30.x series is v2.30.9. But this kind of fix happening is
sufficiently rare and I do not think regular contributors should
have to worry too much about it. If the affected area had tons of
changes between v2.30.9 and 'master', a fix on such an old base
would require a lot of work merging upwards, adjusting to newer
codebase, and it only makes sense to go that length for high value
fixes (aka "security patch"). The rules that apply for such a fix
would be vastly different (e.g. the review may be done behind closed
doors with small number of reviewers, not on the public list).
I think this nugget of knowledge should be included in a v3 of this
series. Will update.
So, while it may help improve understanding of the philosophy behind
the regular procedure to know, I am not sure it is worth spending a
lot of lines to describe it when we are giving a piece of advice for
general "bugfix and/or new development". Some bugs are simply not
worth the trouble of going back for more than two maintenance
tracks to fix.
Thanks.