[Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"

Terry Reedy tjreedy at udel.edu
Wed Nov 9 20:14:38 CET 2011

On 11/9/2011 6:28 AM, Nick Coghlan wrote:

> So bug fixes should be recorded in both places - the 3.3a1 notes
> record the deltas against 3.2.0, not against whatever the latest
> release of 3.2 happens to be when 3.3 is released.

OK, I see that now.

Idea 2: If "What's New in Python 3.3 Alpha 1?" had two major sections" 
NEW FEATURES and BUG FIXES (since 3.2.0) with duplicated subheaders, and 
if the subheaders were tagged, like
Core and Builtins -- Features
Core and Builtins -- Fixes
and if the subheaders for 3.2.z, z>=1 had the latter tags, then the 
context for merges of bug fixes would not be disturbed by the 
interposition of feature items. There would only be a problem when the 
first merge of a subsection for a 3.2.z, z>=2 release is not the first 
item in the corresponding section for 3.3.0alpha1.

Idea 3: Someone else suggested a file-specific merge. If the 3.2.z patch 
simply inserts an item under "Some Header", with no deletions, the 
custom merge inserts the item under the first occurrence of "Some 
Header" in the 3.3 file. Ignoring what comes after in both files should 
prevent new feature items from blocking the merge. Otherwise, use the 
normal merge.

Terry Jan Reedy

More information about the Python-Dev mailing list