René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Formalize discouraged API (= softer deprecations)","articleBody":"### Proposal\r\n\r\nSome parts of our API should not be used anymore. However they are potentially too widely used so that we cannot deprecate them. We sometimes informally use \"soft deprecation\" for these.\r\n\r\nI propose to call these \"discouraged API\" instead and formalize what that means.\r\n\r\n### Details\r\n\r\nTerminology: \"deprecated\" has the connotation of being removed some time in the future. \"soft-deprecated\" is not a well-defined and commonly known term AFAICS. So \"discouraged\" is more clear to the end-user.\r\n\r\nWe'll then have to following categories of API not to be used anymore:\r\n\r\n- *deprecated*: Has a removal version set.\r\n- *pending deprecation*: Is planned to be deprecated in the future. This is essentially a signal to downstream libraries that they should not use this anymore, and can prevent end users seeing deprecation warnings from internal Matplotlib calls of downstream libraries.\r\n- *discouraged*: Should not be used, but will be available indefinitely for backward compatibility.\r\n\r\nDeprecations and pending deprecations have already a formalized way of documentation and warning.\r\n\r\nDiscouraged API should get a corresponding note in the docs. To be discussed whether we also want to warn on it's usage. I tend to say no to not annoy users.\r\n\r\n","author":{"url":"https://github.com/timhoffm","@type":"Person","name":"timhoffm"},"datePublished":"2020-11-26T02:01:21.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":9},"url":"https://github.com/19017/matplotlib/issues/19017"}