I have the same interpretation as stack. However, I think the expectation back when 1.0.0 was rolling out was that we'd have a regular cadence of major releases to use for removing things that had been deprecated. I don't think that cadence has actually happened.
For example, here's a set of major releases and how long it had been since the prior major release at the time it came out: * 0.94 - 4 months * 0.96 - 1.5 years * 0.98 - 4 months * 1.0 - 1 year * 2.0 - 3.25 years If we started a vote today 3.0 would be at 1 year. I suspect it's more likely to end up landing around the 2 year mark. Given this rate and the fact that we've made exceptions in the past (e.g. removing things in 2.0 that were deprecated after 1.0 was already out), should we change our behavior or change what we document to allow removal at a major version without such a long lead time? On Tue, Apr 23, 2019 at 10:17 AM Jan Hentschel <[email protected]> wrote: > > Hi everyone, > > in the PR for HBASE-22262<https://github.com/apache/hbase/pull/162> we > noticed that there could be easily a misunderstanding on when to remove > deprecated methods. In the > book<http://hbase.apache.org/book.html#hbase.versioning.post10> it is > documented “an API needs to be deprecated for a major version before we will > change/remove it.”. As the discussion on the PR shows it leaves some room for > interpretation and should be made more specific, including some examples. I > think we all agree that removing a method in 3.0.0 is ok when it was > deprecated back in 2.0.0, but what do we do with methods or classes which > were deprecated in a minor or patch version? As an example, if we deprecate a > method in 2.3.0, should it be removed in 3.0.0 or 4.0.0? > > Best, Jan
