geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Deppe <jensde...@apache.org>
Subject Re: [DISCUSS] Move or remove org.apache.geode.admin
Date Thu, 04 Apr 2019 13:36:08 GMT
I'm not sure if I'm interpreting various parts of this conversation
correctly, but it seems that one view being assumed is that the actual
removal of deprecated APIs *must* happen in the first version of a major
release bump. i.e. for this discussion that would be *2.0.0*. I don't
believe this is a correct interpretation of the following; taken from
https://semver.org/

Before you completely remove the functionality *in a new major release*
> there should be at least one minor release that contains the deprecation so
> that users can smoothly transition to the new API.


There is no mention of it needing to happen in the *n.0.0* version; just
*sometime* within a new major version.

Given that, these APIs were definitely deprecated before 1.0 and I believe
we're within the definition of *semver* to be free to remove them now.

+1 to removing them any time before 2.0.0.

--Jens

On Wed, Apr 3, 2019 at 7:38 PM Jacob Barrett <jbarrett@pivotal.io> wrote:

> 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 <amurmann@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 <klund@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 <dsmith@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
> >>>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message