You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Dan Smith <ds...@pivotal.io> on 2019/04/03 00:04:36 UTC
[DISCUSS] Move or remove org.apache.geode.admin
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
Re: [DISCUSS] Move or remove org.apache.geode.admin
Posted by Alexander Murmann <am...@apache.org>.
The way I interpret https://semver.org/, deprecated functionality should be
removed in a major release.
Users should be able to update to a new minor release without having to
worry that any of their code will break. It's certainly more convenient for
us to mark as deprecated and then remove whenever after the next major.
It's unrealistic though that users will have kept track of what was
deprecated before the previous major release came around and take that into
account every time they upgrade a minor. In essence we'd expect the user to
keep a list of what previously deprecated functionality they are still
using and treat every minor upgrade like a major until that list is empty.
That would be the only way for them to avoid these potential, very negative
surprises.
That said in this case it sounds like we already have broken large parts of
this API. Regardless of how we chose to interpret semver we should be able
to at least remove the parts of the API that's already broken.
On Tue, Apr 2, 2019 at 6:55 PM Jinmei Liao <ji...@pivotal.io> wrote:
> +1 since it's been deprecated pre geode 1.0, and I have no idea what its
> purpose.
>
> On Tue, Apr 2, 2019 at 5:20 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
> >
> >
> > > On Apr 2, 2019, at 5:04 PM, Dan Smith <ds...@pivotal.io> wrote:
> > >
> > > 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)?
> >
> > I think a deprecated API is no longer API after a major version
> increment.
> > The deprecated symbols can be removed anytime after the major release
> with
> > merely a notice in the release notes. I think its unrealistic to expect
> all
> > deprecated symbols be removed for the x.0 release.
> >
> > > 2) How about in this case, when this feature has been deprecated for so
> > > long, and may or may not work?
> >
> > Given that this API was effectively deprecated in version 0 of Geode and
> > was never part of the release API in 1 it is fair game now. Time should
> not
> > be a factor, just major version number.
> >
> > -Jake
> >
> >
>
> --
> Cheers
>
> Jinmei
>
Re: [DISCUSS] Move or remove org.apache.geode.admin
Posted by Jinmei Liao <ji...@pivotal.io>.
+1 since it's been deprecated pre geode 1.0, and I have no idea what its
purpose.
On Tue, Apr 2, 2019 at 5:20 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
>
> > On Apr 2, 2019, at 5:04 PM, Dan Smith <ds...@pivotal.io> wrote:
> >
> > 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)?
>
> I think a deprecated API is no longer API after a major version increment.
> The deprecated symbols can be removed anytime after the major release with
> merely a notice in the release notes. I think its unrealistic to expect all
> deprecated symbols be removed for the x.0 release.
>
> > 2) How about in this case, when this feature has been deprecated for so
> > long, and may or may not work?
>
> Given that this API was effectively deprecated in version 0 of Geode and
> was never part of the release API in 1 it is fair game now. Time should not
> be a factor, just major version number.
>
> -Jake
>
>
--
Cheers
Jinmei
Re: [DISCUSS] Move or remove org.apache.geode.admin
Posted by Jacob Barrett <jb...@pivotal.io>.
> On Apr 2, 2019, at 5:04 PM, Dan Smith <ds...@pivotal.io> wrote:
>
> 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)?
I think a deprecated API is no longer API after a major version increment. The deprecated symbols can be removed anytime after the major release with merely a notice in the release notes. I think its unrealistic to expect all deprecated symbols be removed for the x.0 release.
> 2) How about in this case, when this feature has been deprecated for so
> long, and may or may not work?
Given that this API was effectively deprecated in version 0 of Geode and was never part of the release API in 1 it is fair game now. Time should not be a factor, just major version number.
-Jake
Re: [DISCUSS] Move or remove org.apache.geode.admin
Posted by Kirk Lund <kl...@apache.org>.
I would be very upset and surprised as a user or developer if Geode never
has any major releases.
Using semver as the main argument to not remove a feature that has been
deprecated for 7 years is silly.
Let’s have a major release! 2.0 by summer.
On Fri, Apr 5, 2019 at 8:38 AM Jacob Barrett <jb...@pivotal.io> wrote:
> I figured I’d take this discussion up with the experts and founding
> fathers. ;)
>
> https://github.com/semver/semver/issues/508
>
> -jake
>
>
> > On Apr 4, 2019, at 8:23 AM, Anthony Baker <ab...@pivotal.io> wrote:
> >
> > Let’s separate the discussion into these parts:
> >
> > - What does SemVer say and how do we apply it
> > - When should we remove deprecated code
> > - Should we remove the admin source code entirely
> >
> >
> > 1) SemVer
> >
> > Straight from the spec:
> >
> >> Major version X (X.y.z | X > 0) MUST be incremented if any backwards
> incompatible changes are introduced to the public API
> >
> > @Jens - doesn’t “new major version” imply n.0.0?
> >
> > Downstream consumers of SemVer-compliant software expect that “backwards
> compatibility” means they can upgrade to a new minor or patch release and
> things will continue to just work—no changes required. If you think about
> how we upgrade our library dependencies we have that same expectation.
> When I upgrade from log4j 2.11.1 to log4j 2.11.2 I don’t expect to have to
> modify any source code.
> >
> > IMO, the clarity that SemVer brings to the question of “Can I upgrade
> safely?” Is its main benefit. If we blur the lines and break stuff without
> signaling via major versions, then our users will be less inclined to trust
> us and will upgrade less frequently IMO.
> >
> > 3) Deprecation
> >
> > Unlike users, SemVer places no value judgement on version numbers and
> assumes that major version numbers are “free” (aka infinite). Some
> projects have major versions like 42.0.0 (wow!). Unfortunately most users
> *do* expect certain things like new features from major versions. And if
> the cost of the upgrade is higher than the value gained from the upgrade
> then there’s a strong disincentive to move forward. We’ve all seen OSS
> communities that have fragmented due to the cost of changing to a new major
> version (e.g. python). I’d sure like to avoid that.
> >
> > Clearly we have a lot of long-deprecated API’s that we want to clean
> up. That’s important to *us*. I also want to understand why our *users*
> will want to upgrade to a geode-2.0.0 release. Let’s spin off a separate
> thread to discuss what that looks like and how we handle the transition
> using branches, prereleases, or other mechanisms to manage breaking changes.
> >
> > 2) Admin source code
> >
> > This is a grey area for me. While technically it is part of the API,
> it’s also true that it’s been broken / unusable (not to mention obsolete)
> for the entire time it’s been part of the geode project. +1 to remove.
> >
> >
> > Anthony
> >
> >
> >> On Apr 4, 2019, at 6:36 AM, Jens Deppe <je...@apache.org> wrote:
> >>
> >> 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 <jb...@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 <am...@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 <ds...@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
> >>>>>>
> >>>>>
> >>>
> >
>
Re: [DISCUSS] Move or remove org.apache.geode.admin
Posted by Jacob Barrett <jb...@pivotal.io>.
I figured I’d take this discussion up with the experts and founding fathers. ;)
https://github.com/semver/semver/issues/508
-jake
> On Apr 4, 2019, at 8:23 AM, Anthony Baker <ab...@pivotal.io> wrote:
>
> Let’s separate the discussion into these parts:
>
> - What does SemVer say and how do we apply it
> - When should we remove deprecated code
> - Should we remove the admin source code entirely
>
>
> 1) SemVer
>
> Straight from the spec:
>
>> Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API
>
> @Jens - doesn’t “new major version” imply n.0.0?
>
> Downstream consumers of SemVer-compliant software expect that “backwards compatibility” means they can upgrade to a new minor or patch release and things will continue to just work—no changes required. If you think about how we upgrade our library dependencies we have that same expectation. When I upgrade from log4j 2.11.1 to log4j 2.11.2 I don’t expect to have to modify any source code.
>
> IMO, the clarity that SemVer brings to the question of “Can I upgrade safely?” Is its main benefit. If we blur the lines and break stuff without signaling via major versions, then our users will be less inclined to trust us and will upgrade less frequently IMO.
>
> 3) Deprecation
>
> Unlike users, SemVer places no value judgement on version numbers and assumes that major version numbers are “free” (aka infinite). Some projects have major versions like 42.0.0 (wow!). Unfortunately most users *do* expect certain things like new features from major versions. And if the cost of the upgrade is higher than the value gained from the upgrade then there’s a strong disincentive to move forward. We’ve all seen OSS communities that have fragmented due to the cost of changing to a new major version (e.g. python). I’d sure like to avoid that.
>
> Clearly we have a lot of long-deprecated API’s that we want to clean up. That’s important to *us*. I also want to understand why our *users* will want to upgrade to a geode-2.0.0 release. Let’s spin off a separate thread to discuss what that looks like and how we handle the transition using branches, prereleases, or other mechanisms to manage breaking changes.
>
> 2) Admin source code
>
> This is a grey area for me. While technically it is part of the API, it’s also true that it’s been broken / unusable (not to mention obsolete) for the entire time it’s been part of the geode project. +1 to remove.
>
>
> Anthony
>
>
>> On Apr 4, 2019, at 6:36 AM, Jens Deppe <je...@apache.org> wrote:
>>
>> 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 <jb...@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 <am...@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 <ds...@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
>>>>>>
>>>>>
>>>
>
Re: [DISCUSS] Move or remove org.apache.geode.admin
Posted by Kirk Lund <kl...@apache.org>.
I believe that putting off a major release such as 2.0 for several years is
an artificial way to prevent ever removing anything that is deprecated.
Following SemVer should be part of a reasonable software release cycle, and
a reasonable software release cycle should involve periodic major releases
for any new features. Releasing 9 or 10 minor releases that include new
features over the last four years looks very much like we're doing
everything possible to not have a major release. If we truly want to follow
SemVer then we should not be including new features in any of these minor
releases either and we should be scheduling periodic major releases. The
only reason I can think of to block a major release would be to prevent
removal of anything that is deprecated. If members of the community want to
indefinitely block removal of anything that is deprecated then please
propose that and then we can vote on that instead. Or if you prefer, please
propose releasing 2.0 instead of 1.10.
On Thu, Apr 4, 2019 at 8:24 AM Anthony Baker <ab...@pivotal.io> wrote:
> Let’s separate the discussion into these parts:
>
> - What does SemVer say and how do we apply it
> - When should we remove deprecated code
> - Should we remove the admin source code entirely
>
>
> 1) SemVer
>
> Straight from the spec:
>
> > Major version X (X.y.z | X > 0) MUST be incremented if any backwards
> incompatible changes are introduced to the public API
>
> @Jens - doesn’t “new major version” imply n.0.0?
>
> Downstream consumers of SemVer-compliant software expect that “backwards
> compatibility” means they can upgrade to a new minor or patch release and
> things will continue to just work—no changes required. If you think about
> how we upgrade our library dependencies we have that same expectation.
> When I upgrade from log4j 2.11.1 to log4j 2.11.2 I don’t expect to have to
> modify any source code.
>
> IMO, the clarity that SemVer brings to the question of “Can I upgrade
> safely?” Is its main benefit. If we blur the lines and break stuff without
> signaling via major versions, then our users will be less inclined to trust
> us and will upgrade less frequently IMO.
>
> 3) Deprecation
>
> Unlike users, SemVer places no value judgement on version numbers and
> assumes that major version numbers are “free” (aka infinite). Some
> projects have major versions like 42.0.0 (wow!). Unfortunately most users
> *do* expect certain things like new features from major versions. And if
> the cost of the upgrade is higher than the value gained from the upgrade
> then there’s a strong disincentive to move forward. We’ve all seen OSS
> communities that have fragmented due to the cost of changing to a new major
> version (e.g. python). I’d sure like to avoid that.
>
> Clearly we have a lot of long-deprecated API’s that we want to clean up.
> That’s important to *us*. I also want to understand why our *users* will
> want to upgrade to a geode-2.0.0 release. Let’s spin off a separate thread
> to discuss what that looks like and how we handle the transition using
> branches, prereleases, or other mechanisms to manage breaking changes.
>
> 2) Admin source code
>
> This is a grey area for me. While technically it is part of the API, it’s
> also true that it’s been broken / unusable (not to mention obsolete) for
> the entire time it’s been part of the geode project. +1 to remove.
>
>
> Anthony
>
>
> > On Apr 4, 2019, at 6:36 AM, Jens Deppe <je...@apache.org> wrote:
> >
> > 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 <jb...@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 <am...@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 <ds...@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
> >>>>>
> >>>>
> >>
>
>
Re: [DISCUSS] Move or remove org.apache.geode.admin
Posted by Anthony Baker <ab...@pivotal.io>.
Let’s separate the discussion into these parts:
- What does SemVer say and how do we apply it
- When should we remove deprecated code
- Should we remove the admin source code entirely
1) SemVer
Straight from the spec:
> Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API
@Jens - doesn’t “new major version” imply n.0.0?
Downstream consumers of SemVer-compliant software expect that “backwards compatibility” means they can upgrade to a new minor or patch release and things will continue to just work—no changes required. If you think about how we upgrade our library dependencies we have that same expectation. When I upgrade from log4j 2.11.1 to log4j 2.11.2 I don’t expect to have to modify any source code.
IMO, the clarity that SemVer brings to the question of “Can I upgrade safely?” Is its main benefit. If we blur the lines and break stuff without signaling via major versions, then our users will be less inclined to trust us and will upgrade less frequently IMO.
3) Deprecation
Unlike users, SemVer places no value judgement on version numbers and assumes that major version numbers are “free” (aka infinite). Some projects have major versions like 42.0.0 (wow!). Unfortunately most users *do* expect certain things like new features from major versions. And if the cost of the upgrade is higher than the value gained from the upgrade then there’s a strong disincentive to move forward. We’ve all seen OSS communities that have fragmented due to the cost of changing to a new major version (e.g. python). I’d sure like to avoid that.
Clearly we have a lot of long-deprecated API’s that we want to clean up. That’s important to *us*. I also want to understand why our *users* will want to upgrade to a geode-2.0.0 release. Let’s spin off a separate thread to discuss what that looks like and how we handle the transition using branches, prereleases, or other mechanisms to manage breaking changes.
2) Admin source code
This is a grey area for me. While technically it is part of the API, it’s also true that it’s been broken / unusable (not to mention obsolete) for the entire time it’s been part of the geode project. +1 to remove.
Anthony
> On Apr 4, 2019, at 6:36 AM, Jens Deppe <je...@apache.org> wrote:
>
> 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 <jb...@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 <am...@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 <ds...@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
>>>>>
>>>>
>>
Re: [DISCUSS] Move or remove org.apache.geode.admin
Posted by Jens Deppe <je...@apache.org>.
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 <jb...@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 <am...@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 <ds...@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
> >>>
> >>
>
Re: [DISCUSS] Move or remove org.apache.geode.admin
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <am...@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 <ds...@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
>>>
>>
Re: [DISCUSS] Move or remove org.apache.geode.admin
Posted by Alexander Murmann <am...@apache.org>.
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 <ds...@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
> >
>
Re: [DISCUSS] Move or remove org.apache.geode.admin
Posted by Kirk Lund <kl...@apache.org>.
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 <ds...@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
>
Re: [DISCUSS] Move or remove org.apache.geode.admin
Posted by Dan Smith <ds...@pivotal.io>.
> But this "hidden" feature, what is that? Is this something that we would
> like to support or is this something that would be replaced with our
> existing efforts in the ConfigurationService and Metrics area.
>
The old JMX agent [1] was superseded by the newer JMX manager [2] sometime
before geode 1.0 was ever shipped. The agent script mentioned in the
javadocs for the old jmx agent was never shipped with geode as far as I can
tell, but you can launch an agent programmatically. Also the link to the
descriptions of the mbeans is broken, but you can get an idea of what
mbeans it had by looking the mbeans-descriptors.xml file in the source.
[1]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/admin/jmx/Agent.html
[2]
https://geode.apache.org/docs/guide/17/managing/management/list_of_mbeans.html
Re: [DISCUSS] Move or remove org.apache.geode.admin
Posted by Udo Kohlmeyer <ud...@apache.org>.
+1 on removing the JMXManager stuff for Geode 2.0 release.
But this "hidden" feature, what is that? Is this something that we would
like to support or is this something that would be replaced with our
existing efforts in the ConfigurationService and Metrics area.
On 4/2/19 17:04, Dan Smith 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
>