On 14 July 2015 at 12:28, Robert Collins <robertc@robertcollins.net> wrote:
On 14 July 2015 at 14:25, R. David Murray <rdmurray@bitdance.com> wrote:
On Tue, 14 Jul 2015 14:01:25 +1200, Robert Collins <robertc@robertcollins.net> wrote:
So unittest.mock regressed during 3.5, and I found out when I released the mock backport.
The regression is pretty shallow - I've applied the fix to 3.6, its a one-liner and comes with a patch.
Whats the process for getting this into 3.5? Its likely to affect a lot of folk using mock (pretty much every OpenStack project got git with it when I released mock 1.1).
3.5 hasn't been released yet. The patch ideally would have gone into 3.5 first, then been merged to 3.6. As it is, you'll apply it to 3.5, and then do a null merge to 3.6. It will get released in the next 3.5 beta.
What I'm unclear on is the approval process for doing ^.
During the beta period, 3.5 is open for normal maintenance (i.e. anything that would be acceptable in a 3.5.1 release). The 3.5 changes that need a +1 from Larry as release manager are the ones where beta feedback reveals an "incomplete feature", where we need to make a more significant change to resolve it that would normally be disallowed on a maintenance branch (e.g. sorting out the data model for PEP 492 after Ben Darnell's attempts to integrate native coroutines with Tornado highlighted a number of shortcomings in the original design). The 3.4 branch also remains open for general maintenance until 3.4.4 goes out, at which put I assume Larry will put that branch into security fix only mode. I wonder: should we start putting some of these process details for the different phases in the release PEPs themselves? Larry sent a good summary to python-committers for 3.5 a while back, but they'd be easier to find in the PEPs, and it would also make it clear which aspects a new RM was keeping, and which they wanted to try doing differently. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia