On Tue, May 31, 2022 at 2:09 PM Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
+1 for a big fat note in the docs (via .. legacy:: directive), preferably with a link to a recommended replacement. -1 for emitting warnings from legacy APIs.
This way, we cater to both legacy uses ("it does the job even though the author graduated a decade ago") and those who write new code.
When an API is declared legacy, I guess, its development stops. All remaining bugs and warts are declared features, we promise to keep it in future versions (until further notice of course, legacy stuff can migrate to deprecated and removed if needs be), and we only promise to keep it working. I.e. if it does not compile on a new python version, we'll try to fix that, but no more. We now have a better way of doing whatever this thing was doing, come join us working on this new bright and shiny thing. Or, if you want things which used to work "forever", great, they keep working just like they did.
I wouldn't necessarily *forbid* bug fixes to *all* things marked as legacy. For some things, like RandomState in numpy, it's warranted because very strict bug-for-bug backwards compatibility has some desirability. For most things that are legacy, the main point is just that bug fixes are at the bottom of our general priority queue. But sometimes a quick fix is simple enough that it rises up on *someone's* priority queue. So committers SHOULD <https://datatracker.ietf.org/doc/html/rfc2119> close bug *reports* on legacy components, and committers (and especially release managers) MAY veto legacy-bug-fixing PRs that are contributed, but could also accept them. -- Robert Kern