Donald is handling the 9.0.x series. Paul just mentioned in IRC that
he'll be doing the 10.x beta in 2 weeks time.
Pip 9.0.2 is out, and the only change it carries is that it supports
TLSv1.2 when running under system Python on macOS < 10.13. Official
release notes: https://pip.pypa.io/en/stable/news/
Context:
*
https://pyfound.blogspot.com/2017/01/time-to-upgrade-your-python-tls-v12.html
* https://github.com/pypa/warehouse/issues/3293
* https://status.python.org/incidents/btjtz01lzp88
--
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc
On 03/07/2018 03:13 PM, Paul Moore wrote:
> Cool, that's good to know. The biggest admin issue I saw was tracking
> "what's suitable for a maintenance release", but certainly my
> impression is coloured by the big changes that went on since 9.0.1.
>
> Paul
>
> On 7 March 2018 at 17:59, Donald Stufft wrote:
>>
>> On Mar 7, 2018, at 12:39 PM, Paul Moore wrote:
>>
>> At the moment,we don't have the infrastructure for doing bugfix
>> releases - and in this specific situation, pulling out the "ready to
>> go" parts of master to form an interim release isn't really practical,
>> given the resources we have. Once pip 10 is out of the door, I'd like
>> to investigate the possibility of having some sort of "maintenance
>> branch" setup, but we're so thin on the ground at the moment (with
>> Donald working on Warehouse and Xavier on leave of absence, it's
>> basically just Pradyun and I, and I'm not managing to actually work on
>> code much, just reviews and issue management) so I don't want to
>> overload what little resource we have with admin.
>>
>>
>>
>> Doing a maintenance release is only a little bit harder than doing a regular
>> release and I don’t think that maintenance branches fix it.
>>
>> If we wanted to we could create a maintenance branch *right now* by just
>> doing ``git checkout -b release/9.0.2 9.0.1`` which would create a branch
>> off of whatever was released as 9.0.1 that we can cherry-pick changes to. I
>> don’t think pre-creating this branch at release time adds anything of value
>> (and in fact I think it makes the situation generally worse).
>>
>> * If changes land to master first and then get cherry-picked into a
>> maintenance branch, then it’s basically no different from what is available
>> today.
>> * If changes land to the maintenance branch first, and then get forward
>> merged to `master`, then people will get confused and send backwards
>> incompatible changes to the maintenance branch and need to be asked to
>> rebase their branch onto master.
>> * Having the branch exist at all will confuse people who don’t know where to
>> send what branch where.
>> * In the past, we’ve had bugs get fixed in a maintenance branch, then forget
>> to merge that into master and “lose” the bug fix.
>>
>> Basically, I think sending changes to the maintenance branch first makes
>> contributing to pip more confusing and more likely we lose things by
>> accident and sending things to `master` branch then asking for a cherry-pick
>> to a maintenance branch isn’t really much less effort than collecting issues
>> at a hypothetical “we want to release 9.0.2” time, creating a branch then,
>> and cherry-picking them all over at that time.
>>
>> In either case, a 9.0.2 release is hard because we vastly altered the
>> structure of the code between 9.0.1 and `master`, so either solution doesn’t
>> really help us get a hypothetical 9.0.2 released with whatever changes we
>> think would be useful. When we don’t have big shifts like that, it’s pretty
>> easy (I’ve done it more than once actually!).