Speaking from the sidelines, I'd say that any further backporting of non-security fixes would appear to be throwing good development effort away,

This software is less than two years from the extremely well-heralded end of its life and people are expecting enhancements? It's a cold, ungrateful world we live in!

It might be useful to retain the issues for the benefit of those who way wish to maintain the release after EOL, or at least get a list of them before the tags are wiped.

regards

Steve

Steve Holden

On Wed, Mar 14, 2018 at 1:16 PM, Michael Scott Cuthbert <cuthbert@mit.edu> wrote:

> it still is in the time period before > EOL that other recent versions have gone to security only. Again, not relevant. You might want to read http://python3statement.org/.

I’m guessing my first message was unclear or able to be misunderstood in some part — I’m one of the frequent contributors to python3statement.org and have moved my own Python projects to Py3 only (the main one, music21, gets its 3.4+-only release this Saturday). I have NO desire to prolong the 2.7 pain.

What I am referring to is the number of “needs backport to 2.7” tags for non-security-related bug-fixes in the issue tracker. (https://github.com/python/cpython/pulls?q=is%3Apr+is%3Aopen+label%3A%22needs+backport+to+2.7%22) My question was between now and 1 Jan 2020 should we still be fixing things in 2.7 that we’re not fixing in 3.5, or leave 2.7 in a security-only mode for the next 21 months? Looking at what has been closed recently, without getting a bpo for actually backporting, it appears that we’re sort of doing this in practice anyhow.

Thanks! and even if my message was read differently than I intended, glad that it had a good effect.

Michael Cuthbert (https://music21-mit.blogspot.com)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com