ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Muzafarov <mmu...@apache.org>
Subject Re: Internal classes are exposed in public API
Date Tue, 04 Feb 2020 10:38:17 GMT
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
View raw message