On 23 August 2015 00:06:44 BST, Chris Angelico <ros...@gmail.com> wrote: >Precisely. Every time you support multiple versions of some >dependency, you have to test your code on all of them, and in the >common case (new features added in newer versions), you have to target >the oldest and weakest version.
Just don't add features to older versions. They're in maintenance or bugfix mode. > When you're writing a Python program >that has to run on CPython back as far as 2.4, there's a lot you can't >do... Just deprecate then drop the stuff you don't want to support any more. This is part of the standard software lifecyle to me. If you care about your users that might not be ready to upgrade provide security fixes for the older versions. If you don't care, well I wouldn't want to use your software in production. > dropping support for everything pre-2.7 lets you improve your >code significantly. Does dropping support for Python 2.4 consist of >"undercutting RHEL users"? Nope. It's that same pragmatism - I want a >cleaner codebase. RHEL 4 might still be supported (is it? haven't paid attention) but there should be no obligation to provide new features. Have a development branch or mainline, that doesn't stop you from having "stable" rele > >CPython 3.4 will continue to run on Windows XP. If you're still using >an old Windows, you just have to keep using an old Python too. >Eventually Python 3.4 will be out of support, but at that point, it's >no different from the OS anyway. There's nothing stopping you from >using an ancient OS, an ancient CPython, and an ancient Python >application, if that's what it requires... I'm not sure what OS people >are running Python 1.5 on, but if anyone complains that it doesn't >install properly on Windows 10, I rather doubt that python.org will >release a patch :) > >ChrisA -- Sent from Kaiten Mail. Please excuse my brevity. -- https://mail.python.org/mailman/listinfo/python-list
