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 <nizhi...@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.goncha...@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. >
