Now that the re fixes are in for py3.7, I think our primary branch for development should be py3.7, with backports to py3.6 if needed. PEP 494 for python 3.6 has that version in a security-fixes-only stage, so we should adopt a similar strategy (although some bug-fixes may be needed, especially around utf8 problems that are still cropping up). Toward that end, I have updated the buildbot configuration to build nightlies off the py3.7 branch instead of the py3.6 branch. So if you wish to obtain a newer build of py3.6, you will need to manually trigger the buildbots. This does not change the status of the default branch. Please let me know if this was too fast and you feel we should continue to use py3.6 as our primary branch for development. Matti
On 26/11/2020 18:16, Matti Picus wrote:
Now that the re fixes are in for py3.7, I think our primary branch for development should be py3.7, with backports to py3.6 if needed. PEP 494 for python 3.6 has that version in a security-fixes-only stage, so we should adopt a similar strategy (although some bug-fixes may be needed, especially around utf8 problems that are still cropping up).
I think it's a bad idea to reverse the direction of merges now. We still have quite a few fixes coming in for 3.6.
Toward that end, I have updated the buildbot configuration to build nightlies off the py3.7 branch instead of the py3.6 branch. So if you wish to obtain a newer build of py3.6, you will need to manually trigger the buildbots.
+1 though ideally we would just run both as nightlies.
This does not change the status of the default branch.
Please let me know if this was too fast and you feel we should continue to use py3.6 as our primary branch for development.
Matti
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
On 11/27/20 7:03 PM, Ronan Lamy wrote:
On 26/11/2020 18:16, Matti Picus wrote:
Now that the re fixes are in for py3.7, I think our primary branch for development should be py3.7, with backports to py3.6 if needed. PEP 494 for python 3.6 has that version in a security-fixes-only stage, so we should adopt a similar strategy (although some bug-fixes may be needed, especially around utf8 problems that are still cropping up).
I think it's a bad idea to reverse the direction of merges now. We still have quite a few fixes coming in for 3.6.
Toward that end, I have updated the buildbot configuration to build nightlies off the py3.7 branch instead of the py3.6 branch. So if you wish to obtain a newer build of py3.6, you will need to manually trigger the buildbots.
+1 though ideally we would just run both as nightlies.
The fixes so far for 3.6 (after the last release) have been - merge from default to fix default attributes in XML (issue 3333) - merges from default to support the py3.7 regex changes - merge from default of rpy-cparser (code rearrangement) - fixing _crypt import - fix utf_8_decode(... final=False) (issue 3348) - merge workaround to detect failed imports intests from default, which exposed missing _opcode builtin module The bug fixes were for XML, utf_8_decode, and _crypt, which could have been backported from py3.7 to py3.6 instead of forward merged from py3.6 to py3.7. Since we depend on contributed machines for our buildbot machines, I do not feel comfortable running 3 nightly builds. To be fair, maybe only the macOSx (contributed by someone who also runs CPython builds) and the windows (which I run on a VM at home) machines would notice the extra load, but it still seems an imposition. So if you accept the limitation of 2 nightly builds on windows and macOSx, which would you choose? Also take into account after we merge the win64 branch, windows runs may become unstable for a while. Matti
participants (2)
-
Matti Picus -
Ronan Lamy