[python-committers] Time for 3.4.9 and 3.5.6
My six-month cadence means it's time for the next releases of 3.4 and 3.5. There haven't been many changes since the last releases--two, to be exact. These two security fixes were backported to both 3.4 and 3.5: * bpo-32981: Fix catastrophic backtracking vulns (GH-5955) * bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) 3.5 also got some doc-only changes related to the online "version switcher" dropdown. (They weren't backported to 3.4 because we don't list 3.4 in the version switcher dropdown anymore.) There are currently no PRs open for either 3.4 or 3.5, and they also have no open "release blocker" or "deferred blocker" bugs. It seems things are pretty quiet in our two security-fixes-only branches--a good way to be! I therefore propose to cut the RCs in a week and a half, and the finals two weeks later. So: Wednesday July 18 2018 - 3.4.9rc1 and 3.5.6rc1 Wednesday August 1 2018 - 3.4.9 final and 3.5.6 final If anybody needs more time I'm totally happy to accommodate them--you can probably have all the time you need. I'm trying to keep to my rough six-month cadence, but honestly that's pretty arbitrary. Thanks to all of you who keep making 3.4 and 3.5 better, //arry/ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Time for 3.4.9 and 3.5.6
08.07.18 10:45, Larry Hastings пише: My six-month cadence means it's time for the next releases of 3.4 and 3.5. There haven't been many changes since the last releases--two, to be exact. These two security fixes were backported to both 3.4 and 3.5: * bpo-32981: Fix catastrophic backtracking vulns (GH-5955) * bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) 3.5 also got some doc-only changes related to the online "version switcher" dropdown. (They weren't backported to 3.4 because we don't list 3.4 in the version switcher dropdown anymore.) There are currently no PRs open for either 3.4 or 3.5, and they also have no open "release blocker" or "deferred blocker" bugs. It seems things are pretty quiet in our two security-fixes-only branches--a good way to be! I suggest to merge a 3.5 specific documentation fix for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW opcodes. There were undocumented changes in 3.5, and third-party projects which implement interpreting or generating these opcodes do it incorrectly. The behavior change was subtle, simple tests will not catch it. https://bugs.python.org/issue33216 https://github.com/python/cpython/pull/6365 ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Time for 3.4.9 and 3.5.6
On 07/08/2018 01:31 AM, Serhiy Storchaka wrote: I suggest to merge a 3.5 specific documentation fix for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW opcodes. There were undocumented changes in 3.5, and third-party projects which implement interpreting or generating these opcodes do it incorrectly. The behavior change was subtle, simple tests will not catch it. https://bugs.python.org/issue33216 https://github.com/python/cpython/pull/6365 I'm happy to consider documentation changes at any time. As far as this change goes: if you look at the PR you'll see I'm the one who closed it. While I acknowledge that the current documentation is imprecise, this PR made the docs inaccurate, and therefore, worse. I'm not sure these minor documentation changes need to be discussed on python-dev. Perhaps you can take future comments back to bpo and GitHub? //arry/ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Time for 3.4.9 and 3.5.6
08.07.18 13:02, Larry Hastings пише: On 07/08/2018 01:31 AM, Serhiy Storchaka wrote: I suggest to merge a 3.5 specific documentation fix for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW opcodes. There were undocumented changes in 3.5, and third-party projects which implement interpreting or generating these opcodes do it incorrectly. The behavior change was subtle, simple tests will not catch it. https://bugs.python.org/issue33216 https://github.com/python/cpython/pull/6365 I'm happy to consider documentation changes at any time. As far as this change goes: if you look at the PR you'll see I'm the one who closed it. While I acknowledge that the current documentation is imprecise, this PR made the docs inaccurate, and therefore, worse. The current documentation is not just imprecise, it is wrong. My English is so bad that I don't understand what is wrong with the proposed PR. To me, it adds correct information. Would be nice if you or other native English speaker suggest better wording. This is not a minor documentation change, this is a fix of a single official documentation about CPython bytecode. I'm sorry for reminding about this issue. I thought you forgot about it. This issue was open for 3.5 and marked as "release blocker", but you have not mentioned it. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Time for 3.4.9 and 3.5.6
OTOH, we're talking about a doc fix for a very old version. Surely people who rely on the documented opcodes there have already fixed their software to deal with the discrepancy. Regards Antoine. Le 08/07/2018 à 18:44, Serhiy Storchaka a écrit : > 08.07.18 13:02, Larry Hastings пише: >> On 07/08/2018 01:31 AM, Serhiy Storchaka wrote: >>> I suggest to merge a 3.5 specific documentation fix for >>> CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW opcodes. There were >>> undocumented changes in 3.5, and third-party projects which implement >>> interpreting or generating these opcodes do it incorrectly. The >>> behavior change was subtle, simple tests will not catch it. >>> >>> https://bugs.python.org/issue33216 >>> https://github.com/python/cpython/pull/6365 >> >> I'm happy to consider documentation changes at any time. As far as this >> change goes: if you look at the PR you'll see I'm the one who closed >> it. While I acknowledge that the current documentation is imprecise, >> this PR made the docs inaccurate, and therefore, worse. > > The current documentation is not just imprecise, it is wrong. My English > is so bad that I don't understand what is wrong with the proposed PR. To > me, it adds correct information. Would be nice if you or other native > English speaker suggest better wording. This is not a minor > documentation change, this is a fix of a single official documentation > about CPython bytecode. > > I'm sorry for reminding about this issue. I thought you forgot about it. > This issue was open for 3.5 and marked as "release blocker", but you > have not mentioned it. > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
