It wasn't clear to me after reading the "Forward Porting" section exactly what was going on. Nick Coghlan spelled it out for me in a private email, and suggested that maybe this stuff should be in the devguide proper. Here's some specific stuff that I didn't understand until Nick explained it to me with simple words: * 2.x and 3.x have separate heads in the same repository * Since they're totally divorced, the order you check in to 2.x and 3.x does not matter * DO NOT MERGE between 2.x and 3.x * Branches that are in security-fix-only mode (e.g. 3.1) don't get bugfixes or documentation fixes (surely mentioned elsewhere, but I personally would have been helped with a reminder) I suggest it'd be clearer to start with discussing "2.x and 3.x are separate heads", and *then* move on to "But when merging changes solely inside a major version" and talk about forward-porting. Would you be interested in a patch?
This was from memory, so don't take it as gospel as far as the current security-fix-only branches go, but here's what I sent to Larry: ----------------- We maintain two independent heads in hg: 2.7 and default 3.2 is open for general bugfixes 2.5 (IIRC), 2.6 and 3.1 are open for security fixes Security fixes (if applicable to both heads) go: 2.5 -> 2.6 -> 2.7 3.1 -> 3.2 -> default General bug fixes (if applicable to both heads) go: 2.7 3.2 -> default New features are added to default only The relative ordering of 2.x and 3.x changes doesn't really matter - the important thing is not to merge them in *either* direction. I think you can theoretically do cherry-picking with Hg, but most people seem to just do independent commits to the two streams. -----------------
What follows is the original email from Nick. -- We maintain two independent heads in hg: 2.7 and default 3.2 is open for general bugfixes 2.5 (IIRC), 2.6 and 3.1 are open for security fixes Security fixes (if applicable to both heads) go: 2.5 -> 2.6 -> 2.7 3.1 -> 3.2 -> default General bug fixes (if applicable to both heads) go: 2.7 3.2 -> default New features are added to default only The relative ordering of 2.x and 3.x changes doesn't really matter - the important thing is not to merge them in *either* direction. I think you can theoretically do cherry-picking with Hg, but most people seem to just do independent commits to the two streams. If the devguide doesn't align with the above, then a tracker issue pointing that out would be handy :)
The devguide actually did align with what I said in my email, but this wasn't clear if you only read the "Forward Porting" section (you had to read the "Porting Between Major Versions" section further down the page as well). I added a new paragraph to the forward porting section so it describes the whole policy, leaving the following two sections to cover the mechanics of actually handling that with Mercurial.
History
Date
User
Action
Args
2022-04-11 14:57:22
admin
set
github: 57314
2011-10-23 11:07:16
ncoghlan
set
status: open -> closedresolution: fixedmessages: +
