On 11/27/2019 10:38 AM, Brett Cannon wrote:
What do people think of the idea of requiring all deprecations specifying a version that the feature will be removed in (which under our annual release cadence would be at least the third release from the start of the deprecation, hence the deprecation being public for 2 years)? And that we also follow through with that removal?
I would advocate for a plan in which removals happen every so many releases -- in other words, if a removal release is being prepped and a feature has been deprecated for at least two cycles, toss it. With a yearly cadence I would suggest every 5 years. I.E. deprecated removed ---------- ------- 3.6 3.10 3.7 3.10 3.8 3.10 3.9 3.15 3.10 3.15 This way folks know that upgrading from 3.8 to 3.9 should be painless, but going to 3.10 will require more careful search for deprecations. It also serves as a reminder for us to double-check for needed removals on */5 releases. -- ~Ethan~ _______________________________________________ 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/4NYXNSXWETVXVSPXIXAXDVLYUGVBIJFR/ Code of Conduct: http://python.org/psf/codeofconduct/
