[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