On Tue, Apr 23, 2019 at 9:04 PM Zach York <zyork.contribut...@gmail.com> wrote:
> Always good to see the history of the discussion :) It looks like nothing > really was decided last time (use caution if removing before a full major > version), hopefully we can come up with something more descriptive this > time. > Yeah, I followed through with the deprecations back then. From the tickets that Jan created, I believe most of them were added by me (I mean the descriptions on when each thing would be removed). What I did _not_ follow through on though (I must have forgotten) is to update the book to better explain how we understood the policy back then. Thank you, Jan for bringing this up again and working on removing those deprecations. It'd be great if we could fix it this time. I don't really have a strong opinion though. As far as I'm concerned I'm happy keeping things in for a whole major version (e.g things need to be deprecated in 2.0.0 so they can be removed in 3.0.0). If we want to remove a deprecation then that alone can be a good reason to do (or to speed up) a new major release. I'm very much against a time-based deprecation policy (I see that Sean already pointed out the same) as there can be 12 releases in 6 months or 0. I would also very much like to see deprecations being more important during reviews. In my opinion, a missing deprecation comment without a clear explanation should block a patch. It adds a lot of technical-debt and can be time-consuming to chase up the reason why something was deprecated. Cheers, Lars
