hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Francke <lars.fran...@gmail.com>
Subject Re: [DISCUSS] Handling removal of deprecated methods and classes
Date Thu, 25 Apr 2019 14:22:04 GMT
On Tue, Apr 23, 2019 at 9:04 PM Zach York <zyork.contribution@gmail.com>

> 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message