1) +1 YES. If we continue to *not* have at least one major release per year, then I 100% support the removal of deprecated APIs and features in a minor release such as 1.10. If we decide to have at least one major release per year, then I'd be willing to revisit this and consider not allowing removal in a minor release. I do *not* support perpetually deferring major releases to avoid facing the removal of deprecated APIs -- that's just ridiculous as it keeps our maintenance costs much higher than they need to be.
2) +1 to remove anything in 1.10, or any other minor release, that was already deprecated in Geode 1.0 On Tue, Apr 2, 2019 at 5:05 PM Dan Smith <dsm...@pivotal.io> wrote: > Hi devs, > > The org.apache.geode.admin package has been deprecated for about 7 years > [1]. > > I'd like to remove it, or at least move it to a separate module. I actually > started some work to move it to a separate module [2]. However in the > course of this process, I've found that this module has extremely little > test coverage, so I'm not confident in the move. For example, it has a > whole JMX manager feature (different than our current JMX manager) which > does not appear to have any tests. This JMX manager feature won't work as > shipped unless you find and add some mx4j jars to your classpath. > > I think the best course of action is probably to remove it entirely. > However, this does bring up a couple of questions: > > 1) Is it ok in general to remove deprecated API in a non X.0 release (eg > geode 1.10 instead of geode 2.0)? > > 2) How about in this case, when this feature has been deprecated for so > long, and may or may not work? > > -Dan > > [1] > > https://geode.apache.org/releases/latest/javadoc/org/apache/geode/admin/package-summary.html > [2] Draft PR for moving the org.apache.geode.admin to a separate module - > https://github.com/apache/geode/pull/3392 >
