A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2011-November/114420.html below:

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

[Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"Nick Coghlan ncoghlan at gmail.com
Wed Nov 9 23:01:35 CET 2011
On Thu, Nov 10, 2011 at 5:14 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> 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.

Alas, things sometimes don't divide that cleanly - sometimes an API
change/addition is part of fixing a bug rather than a new feature in
its own right.

A custom merge function along the lines of the one you suggest (i.e.
if it's after a section header in 3.2.x Misc/NEWS, add it after the
first occurrence of the same header in 3.3) is probably the way to go.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4