I now see that this is a thread from a year ago and that the PR is already merged. S.Y. Lee's comment made me think this was a new thread. I probably wouldn't have written this if I new this was old.
Jason moorepants.info +01 530-601-9791 On Sun, Jan 15, 2023 at 1:26 PM Jason Moore <moorepa...@gmail.com> wrote: > 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/CAP7f1AiazYWp8ukqtafKVQmBMGewHGPt3%2B8fr%2BEdsgLUXKYJbQ%40mail.gmail.com.
