1 year seems too short from my perspective. As a downstream package maintainer, I release many packages less often than SymPy makes releases and keeping up with deprecations disappearing effectively each SymPy release would be stressful. I would advocate for at least 2 years, which equates to at least a couple of SymPy releases. Or even stating something like "deprecations can be removed if they've existed both for two years and two SymPy releases".
I also think the current method of leaving the deprecations in indefinitely is fine and preferable. I don't think having a policy written in a way that encourages people to constantly look for deprecations that are just over the minimum time period to immediately remove them. They should really only be removed when they both reach the minimum AND are causing some issue with new code refactoring or designs. Jason moorepants.info +01 530-601-9791 On Wed, Jan 26, 2022 at 10:38 PM Aaron Meurer <asmeu...@gmail.com> wrote: > We are currently in the process of revamping our deprecations policy > at https://github.com/sympy/sympy/pull/22900, and we would like any > feedback from the community, both users and developers. Our current > policy that this would replace is on the wiki > https://github.com/sympy/sympy/wiki/Deprecating-policy. > > In particular, the new policy would have > > 1. An official period of at least 1 year for all deprecations to last. > Previously there was no official period for deprecations, and > deprecated functionality was removed more or less whenever we felt > like it. > > 2. Deprecations will still raise a SymPyDeprecationWarning, but the > proposed policy is to make the warnings contain much more verbose and > helpful messages. In addition, all warnings will be documented in the > respective docstrings, listed in a separate "all active deprecations" > document in the docs, and listed in the release notes for each release > (currently only the last of these is done). > > 3. The current silly "deprecation removal issue" thing that we (tried) > to do will be removed. All documentation for deprecations will be in > the documentation. > > 4. I have added some text to the document going over when backwards > compatibility breaks should be made (tl;dr: sparingly), and what does > and doesn't require deprecation to change. The document also has > developer instructions on how to add a deprecation to the code. > > One question we have for users is if you are happy with our current > SymPyDeprecationWarnings, which are relatively loud by default (they > use a warnings filter that always turns them on). Would you prefer > more silent warnings, like warnings that are documented but aren't > accompanied by a warning printed to the screen? > > Aaron Meurer > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sympy+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAKgW%3D6JkAa0jbEDKPHy7p6yVpjB8pBomcinV%3Dp-UdaBD_hiQhw%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1Ag9BVr9nmzAYizmXRvhDK4tKdJqnkD4GA%3DPJgbBwtkeOw%40mail.gmail.com.
