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.
I think the idea of having a tag/annotation for detailing when the method/feature is set for removal is a cool idea that we should investigate further. If every deprecated method/feature had such an annotation, it would be easy to build automation around generating release notes/documentation on what was removed in a particular version (instead of relying on someone to manually update the release note/docs). I agree that major releases are taking a long time to release and that causes deprecated features to hang around for a long time, but I also feel like moving it to >= 1 minor release is a bit too quick and would add to upgrade burden. Not everyone uses every minor version so they might be taken unaware by the change or be less likely to upgrade as quickly. I'm not necessarily against shortening the time. Maybe there is some sort of middle ground (>=2 minor releases), but that gets a little muddy and would need to be documented heavily. Thanks, Zach On Tue, Apr 23, 2019 at 9:37 AM Lars Francke <[email protected]> wrote: > We had this exact same discussion four years ago (I thought it was last > year :O ): < > > https://lists.apache.org/thread.html/bbdbf135abe7d8a0a4e7e9563f0bdc3dd6b555a0d3cdc1b1fdd688c2@1427759561@%3Cdev.hbase.apache.org%3E > > > > On Tue, Apr 23, 2019 at 6:32 PM Sean Busbey <[email protected]> wrote: > > > 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 > > >
