Thanks for the discussion. Based on the discussion I opened HBASE-22341<https://issues.apache.org/jira/browse/HBASE-22341> to make the documentation more explicit. I will provide a PR in a few minutes. Additionally I’ll open a ticket later to document our code, where we deprecated an API, but did not state when it was deprecated. This should make it more obvious when we deprecated an API and when we’re going to remove it.
Best, Jan From: Lars Francke <lars.fran...@gmail.com> Reply-To: "dev@hbase.apache.org" <dev@hbase.apache.org> Date: Thursday, April 25, 2019 at 4:22 PM To: "dev@hbase.apache.org" <dev@hbase.apache.org> Subject: Re: [DISCUSS] Handling removal of deprecated methods and classes On Tue, Apr 23, 2019 at 9:04 PM Zach York <zyork.contribut...@gmail.com<mailto: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
