That’s your interpretation of semver. I interpret The API not to be broken within a major as those that are still valid when the major is released despite the availability of deprecated symbols from previous major. Just because I can access symbols does not make it API. API is the combination of documentation, annotation and availability of the symbols. If the symbols are available but marked deprecated and not documented anymore then it is. It API.
Yes under your interpretation it would require that availability be removed at the major release too so that a consumer that ignore deprecation warnings when compiling with the new version got a compilation or runtime error later up updating a minor. I think that error is well deserved. We do a disservice to our customers by allowing them to continue to limp along on deprecated, unmaintained and untested APIs because we missed an arbitrary window to remove the symbols. If however the community agrees with you interpretation then we must make sure a ticket is created for the next major with a list of deprecated items and updated when new items are deprecated so that the task is performed at the major release. A chore needs to be undertaken to remove all deprecated APIs at the start of each major development cycle. The short of it is we can’t miss this arbitrarily limiting window. -Jake > On Apr 3, 2019, at 3:58 PM, Alexander Murmann <amurm...@apache.org> wrote: > > Would we announce that we aren't following semver anymore because bumping > the major version is somehow too expensive? > >> On Wed, Apr 3, 2019 at 3:29 PM Kirk Lund <kl...@apache.org> wrote: >> >> 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 >>> >>
