ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Internal classes are exposed in public API
Date Tue, 04 Feb 2020 19:59:36 GMT
Let's run a vote if that's the only option to come to a consensus. It will
be best if either Alex Goncharuk, Andrey Gura or Nikolay Izhikov creates a
discussion thread stating the problem and possible choices. Folks, who
would like to take over?

Generally, the vote should help us to decide how to deal with similar
situations in the future. We need to agree on how and in what circumstances
we deprecate existing APIs and engrave this on our wiki. As for this
discussion related to the new metrics framework, it should be used just as
a reference.

-
Denis


On Tue, Feb 4, 2020 at 2:38 AM Maxim Muzafarov <mmuzaf@apache.org> wrote:

> Folks,
>
> Let's start a vote?
>
> On Mon, 3 Feb 2020 at 15:05, Andrey Gura <agura@apache.org> wrote:
> >
> > Just post here article from Oracle documentation "How and When To
> > Deprecate APIs" [1].
> >
> > [1]
> https://docs.oracle.com/javase/8/docs/technotes/guides/javadoc/deprecation/deprecation.html
> >
> > On Fri, Jan 31, 2020 at 10:44 AM Pavel Tupitsyn <ptupitsyn@apache.org>
> wrote:
> > >
> > > Agree with Andrey, let's remove deprecation for now and unblock the
> release.
> > >
> > > On Thu, Jan 30, 2020 at 10:23 PM Andrey Gura <agura@apache.org> wrote:
> > >
> > > > I'll just repeat one thought with some changes.
> > > >
> > > > There are at least two groups of people in this discussion. One group
> > > > sure that new API is complete and production ready while other group
> > > > disagree with it. Obviously we can't reach consensus about it right
> > > > now. But we can do it in the future.
> > > > At present we just can't deprecate existing API and mark new API as
> > > > experimental at the same time. So we must remove deprecation until
> the
> > > > consensus is reached.
> > > >
> > > > Also there is the third group of people. This people aren't related
> > > > with the API, they may be don't need the API and they wait for bug
> > > > fixes and other features. It is very easy to satisfy third group:
> just
> > > > cut off what caused the release blocking. But it is much easier to
> > > > remove @deprecated annotations.
> > > >
> > > > On Thu, Jan 30, 2020 at 8:54 PM Nikolay Izhikov <nizhikov@apache.org
> >
> > > > wrote:
> > > > >
> > > > > Alexey.
> > > > >
> > > > > I answered to your examples and issues you provide.
> > > > > But, it seems the discussion of the API and the Java code itself
> is not
> > > > the goal of this thread anymore.
> > > > >
> > > > > > Should we provide a way to know the number of metrics and
> registries
> > > > in advance?
> > > > >
> > > > > No.
> > > > > If you think this is the real use-as let’s add `size` methods.
> > > > > It will be the simple API *extension*.
> > > > >
> > > > > > There is no separation on public and internal metrics
> > > > >
> > > > > Any metric can be changed(removed) in any time.
> > > > > But we will try not to do it unless we have a strong reason.
> > > > >
> > > > > > Will we allow users to register their own metrics?
> > > > >
> > > > > No.
> > > > >
> > > > > > It's still not clear how a user will map old interfaces and
> methods to
> > > > the new metric names.
> > > > >
> > > > > We should write this information in the deprecation message.
> > > > >
> > > > > > 30 янв. 2020 г., в 20:27, Alexey Goncharuk <
> alexey.goncharuk@gmail.com>
> > > > написал(а):
> > > > > >
> > > > > > Nikita,
> > > > > >
> > > > > > Disagree here. I already gave an example in this thread of how
> you
> > > > need to
> > > > > > peek into configuration in order to obtain an instance of
> exporter SPI
> > > > > > which may not necessarily be the type you need. That's why
> > > > IGNITE-12553 was
> > > > > > created in the first place.
> > > > >
> > > >
>

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