On Wed, Dec 9, 2020 at 10:16 AM Gregory P. Smith <g...@krypto.org> wrote:
> > > As a meta question: Is there a good reason to support binaries running on > macOS earlier than ~ $latest_version-1? > > Aren't systems running those old releases rather than upgrading > unsupported by Apple, never to be patched, and thus not wise to even have > on a network? > I don't know if Apple has a written policy on support for older versions of macOS. Looking at https://support.apple.com/en-us/HT201222 it suggests that macOS 10.13 High Sierra got an update last month, but 10.12 has not been updated since September 2019. > > Yes, that means some very old hardware becomes useless as Apple drops > support. But that is what people signed up for when they bought it. Why > should that be our problem? > > (It sounds like y'all will make it work, that's great! I'm really just > wondering where the motivation comes from) > I would be supportive of saying our support policy for macOS is up to one year after the last security update which would mean we would support 10.13 and newer which was released September 2017. (Honestly, I would be fine with 6 months since Apple seems to make security releases frequently enough to use that as an indicator that they have dropped support, but one year seems more "reasonable" as a way to not accidentally cut support off prematurely.) -Brett > > -gps > > On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc <gregory.sz...@gmail.com> > wrote: > >> On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren <ronaldousso...@mac.com> >> wrote: >> >>> >>> >>> On 8 Dec 2020, at 19:59, Gregory Szorc <gregory.sz...@gmail.com> wrote: >>> >>> Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding >>> macOS. >>> >>> Without the changes from https://github.com/python/cpython/pull/22855 >>> backported, attempting to build a portable binary on macOS 11 (e.g. by >>> setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: >>> 'XXX' is only available on macOS 10.13 or newer >>> [-Wunguarded-availability-new]` warnings during the build. This warning >>> could be innocuous if there is run-time probing in place (the symbols in >>> question are weakly linked, which is good). But if I'm reading the code >>> correctly, run-time probing was introduced by commits like eee543722 and >>> isn't present in 3.8.7rc1. >>> >>> I don't have a machine with older macOS sitting around to test, but I'm >>> fairly certain the lack of these patches means binaries built on macOS 11 >>> will blow up at run-time when run on older macOS versions. >>> >>> These same patches also taught CPython to build and run properly on >>> Apple ARM hardware. I suspect some people will care about these being >>> backported to 3.8. >>> >>> We know. Backporting the relevant changes to 3.8 is taking more time >>> than I had hoped. It doesn’t help that I’ve been busy at work and don’t >>> have as much energy during the weekend as I’d like. >>> >>> The backport to 3.9 was fairly easy because there were few changes >>> between master and the 3.9 branch at the time. Sadly there have been >>> conflicting changes since 3.8 was forked (in particular in posixmodule.c). >>> >>> The current best practice for building binaries that work on macOS 10.9 >>> is to build on that release (or rather, with that SDK). That doesn’t help >>> if you want to build Universal 2 binaries though. >>> >> >> Thank you for your hard work devising the patches and working to backport >> them. >> >> I personally care a lot about these patches and I have the technical >> competency to perform the backport. If you need help, I could potentially >> find time to hack on it. Just email me privately (or ping @indygreg on >> GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely >> cherry pick the patches for >> https://github.com/indygreg/python-build-standalone. And I'm sure other >> downstream packagers will want them as well. So having them in an >> unreleased 3.8 branch is better than not having them at all. >> _______________________________________________ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@python.org >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2POTPNVW72VUPCPTJIOA6AOSVWY/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/Q45VNQYOYXTRRTA26Q4M2WNXPFKL4S2O/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/P5ZK2QXPEUQELJMAHSLXFV3H3BKPQBTL/ Code of Conduct: http://python.org/psf/codeofconduct/
