Re: Internal classes are exposed in public API

[Andrey Gura <ag...@apache.org>]

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 <pt...@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 <ag...@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 <ni...@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 <al...@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.
> > >
> >

Re: Internal classes are exposed in public API

[Alexey Goncharuk <al...@gmail.com>]

The discussion thread is started:
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Public-API-deprecation-rules-td45647.html

ср, 5 февр. 2020 г. в 12:43, Alexey Goncharuk <al...@gmail.com>:

> Sorry for the rush, I think I got it - it's right in the voting process
> [1]. This would be a vote on a procedural issue of how to handle code
> deprecation.
>
> I'll start the discussion soon, let's agree on the alternatives and then
> start the vote.
>
> [1] https://www.apache.org/foundation/voting.html
>

Re: Internal classes are exposed in public API

[Alexey Goncharuk <al...@gmail.com>]

Sorry for the rush, I think I got it - it's right in the voting process
[1]. This would be a vote on a procedural issue of how to handle code
deprecation.

I'll start the discussion soon, let's agree on the alternatives and then
start the vote.

[1] https://www.apache.org/foundation/voting.html

Re: Internal classes are exposed in public API

[Alexey Goncharuk <al...@gmail.com>]

Denis,

I just realized that this vote would not be a regular Apache vote we used
to run. Usually we vote for a change to be accepted or rejected. Here, on
the other hand, we need to choose between two alternatives, and I am not
sure yet how this should be formally handled.

Dmitriy, perhaps, you can shed some light on this? Meanwhile, I'll brush up
on the voting process as well.

Re: Internal classes are exposed in public API

[Denis Magda <dm...@apache.org>]

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 <mm...@apache.org> wrote:

> Folks,
>
> Let's start a vote?
>
> On Mon, 3 Feb 2020 at 15:05, Andrey Gura <ag...@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 <pt...@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 <ag...@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.
> > > > >
> > > >
>

Re: Internal classes are exposed in public API

[Maxim Muzafarov <mm...@apache.org>]

Folks,

Let's start a vote?

On Mon, 3 Feb 2020 at 15:05, Andrey Gura <ag...@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 <pt...@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 <ag...@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 <ni...@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 <al...@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.
> > > >
> > >