Hi all, Thanks for bringing this up, Jorge!
I'm not sure if we have a documented rule; I seem to recall having had the same discussion for 2.0. My personal suggestion would be to have a deprecation period of at least one year, and beyond that to weigh how good we feel about removing each deprecated member. I.e., if a member was deprecated just barely over a year ago, and it doesn't do any harm, and we know it's widely used, maybe we hold off. But if a member was deprecated two years ago, even if we know it was widely used, we should probably just get rid of it. The key thing to bear in mind is that deprecation itself is just a "yellow light" to warn people that a member is going away so we can avoid disruption when they upgrade from one release to another. I.e., the target audience is human beings. The deprecation period should be measured in human time rather than number of releases for this reason. The key question is, "What's the likelihood that almost everyone has at least had an opportunity to encounter the deprecation warning before we drop the method?" If the answer is, "The likelihood is high," then we should drop it. Note, this is also a good argument for _not_ having a strict policy but just considering the circumstances each major release. In this case, I feel pretty good about dropping it. 2.1.0 will have been released over two years ago by the time of the 3.0 release. Of course, some people are very conservative and are still running 1.x versions. But I'd argue that by the nature of their conservatism, these folks are unlikely to upgrade from 1.x straight to 3.x. They'd probably stop over in the 2.x series for a while first. Further, they probably wouldn't just pick 2.0.0. If it were me, I'd pick a release that had been out for around a year and that has gotten several patches. So, 2.2.2? Either way, it seems like 2.1 deprecations should be ok to drop. Thanks, -John On Mon, 2020-08-31 at 21:02 -0700, Sophie Blee-Goldman wrote: > Thanks for this KIP as well! Seems like the methods were deprecated in 2.1. > What's our rule for how something has to stay deprecated before we can go > ahead and remove it? > > Assuming 3.0 comes after 2.8, it certainly seems like enough time/releases > have > passed for us to do so in 3.0. But I'm pretty sure that the deprecation > rule follows > a specific number that I'm just not remembering, so hopefully someone else > can > jump in with an official quote here. > > > > On Fri, Aug 28, 2020 at 11:32 AM Jorge Esteban Quilcate Otoya < > quilcate.jo...@gmail.com> wrote: > > > Hi everyone, > > > > I'd like to propose these changes to the Window Store API. > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-667%3A+Remove+deprecated+methods+from+ReadOnlyWindowStore > > > > As these changes involve removing deprecated methods, this KIP is targeting > > the next major release v3.0. > > > > Looking forward to your feedback. > > > > Cheers, > > Jorge > >
