[Python-Dev] Proposed schedule for 3.4.2 (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Mon Sep 8 14:08:21 CEST 2014
- Previous message: [Python-Dev] Proposed schedule for 3.4.2
- Next message: [Python-Dev] Proposed schedule for 3.4.2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 8 September 2014 14:28, Ned Deily <nad at acm.org> wrote:
In article <540C521C.7070802 at hastings.org>, Larry Hastings <larry at hastings.org> wrote:
Matthias asked me when I was going to release 3.4.2. I propose the following schedule:
Tag 3.4.2rc1 Friday Sep 12 2014 Release 3.4.2rc1 Saturday Sep 13 2014 Tag 3.4.2 final Saturday Sep 27 2014 Release 3.4.2 final Sunday Sep 28 2014 Normally I want to tag on Saturdays and release on Sundays, however I propose moving rc1 a day earlier because I'll be unavailable that Sunday. Any objections? I will interpret silence as tacit approval. As I've already discussed with Larry, I think adding a week to the scheduled dates would be preferable. The original dates give pretty short notice and there are a number of open issues that would be good to resolve now in 3.4.2.
It would also be good to get Guido's official verdict on PEP 476 (the switch to validating HTTPS by default) in time for 3.4.2. Based on the previous discussion, Alex updated the PEP to suggest "just fix it" for all of 3.5, 3.4.x and 2.7.x (including the httplib SSLContext support backport in the latter case).
I think that would be feasible with an rc on the 20th, but challenging if the rc is this coming weekend.
Note, as I stated in the previous thread, I'm now +1 on that PEP, because I don't see any way to write an automated scan for a large code base that ensures we're not relying on the default handling at all. If the default behaviour is to validate HTTPS, the lack of such a scanner isn't a problem - any failures to cope with self-signed or invalid certs will be noisy, and we can either fix the certs, patch the code to cope with them appropriately, or (for the self-signed cert case) configure OpenSSL via environment variables. If dealing with invalid certs is truly necessary, and the code can't be updated either, then I'm OK with the answer being "keep using an older version of Python, as that's going to be the least of your security concerns".
Regards, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] Proposed schedule for 3.4.2
- Next message: [Python-Dev] Proposed schedule for 3.4.2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]