Ethan Furman wrote: > 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 there is other things that might break your code between releases, such as bug fixes, language changes that become the default, etc. Are deprecations the biggest pain point in transitioning to a new Python version for people, or is it just part of a greater culmination of changes? > 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. For some reason this makes the "clean up" release feel like an anti-LTS because it's like, "3.9 works, 3.10 works, 3.11 works, 3.12 works, 3.13 works, 3.14 works, boom!" _______________________________________________ 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/ZCZHVLN72RWKSJREZAZACFCF3WVT6F3V/ Code of Conduct: http://python.org/psf/codeofconduct/
