Hi Igniters,
Let me share some thoughts. Abstractly.
1. @Experimental API. When user see API marked as experimental usually it
is a red flag for using such API in prod
and also he can't count the API stability:
- API itself if not stable and one can have compilation issues with next
versions at least
- API semantic can be changed that can cause full API usage revision and
even rewrite code that use this API.
So, user expects API (and its implementation) is offered to user e.g. to
check if some user issues can be resolved with new API
or e.g. for review to developers can get some feedback.
2. @Deprecated API. From my point of view: Deprecation is not about "we
mark code to inform user\dev about legacy".
When user see deprecation he interpret this as a strict directive to use a
new API.
He expects the API is still workable (unless there is no notes that API is
totaly broken of course), but definitely expects a new stable API must
exist.
It is ok if old API have less capabilities or even have huge limitations.
Concrete.
1. Let's mark new metrics API as Experimental. This allow us to add any
changes in future minor releases to resolve known issues.
2. AFAIR, we have strong commitment to not change\delete old API between
minor releases.
We can't mark old metrics as deprecated regarding user expectations
described before.
Let's make old API as deprecated in *one of future minor* release, once a
new one will be considered as *stable*.
I'm not sure we even can forbid anyone to contribute to old API for now and
then until (in 3.0) it will be decided old API for removal via Voting.
On Thu, Jan 30, 2020 at 2:47 PM Maxim Muzafarov <mmu...@apache.org> wrote:
> Igniters,
>
>
> How about to start a vote (formal) over the whole community to choose
> between these two options we have? With one caveat that veto votes are not
> applicable to this discussion. Let the whole community decide what
> direction we should move on.
>
> On Thu, 30 Jan 2020 at 14:34, Nikolay Izhikov <nizhi...@apache.org> wrote:
>
> > Hello.
> >
> > > 2. Add @IgniteExperimetnal to new API (because... see item. 1
> >
> > +1
> >
> > > 1. Remove @Deprecated from old API (because it strange to have one
> > deprecated API and second experimental API)
> >
> > -1
> >
> > I propose to update deprecation message and provide metric name for each
> > deprecated method.
> >
> > > @deprecated Use {@link JmxMetricExporterSPI} instead. Name of the
> metric
> > «io.dataregion.pageCount»
> >
> > Andrey.
> >
> > We doesn’t come to an agreement that API should be changed.
> > We should discuss the design of the Metric API and your proposals for it
> > in another thread.
> >
> > Please, avoid arguments like «this API will be 100% changed» in this
> > discussion.
> >
> > > 30 янв. 2020 г., в 14:21, Andrey Gura <ag...@apache.org> написал(а):
> > >
> > > From my point of view we still don't have consensus.
> > >
> > > I think we should do at least the following:
> > >
> > > 1. Remove @Deprecated from old API (because it strange to have one
> > > deprecated API and second experimental API)
> > > 2. Add @IgniteExperimetnal to new API (because... see item. 1)
> > > 3. Do not merge IGNITE-12553 (because it adds new public interface
> > > that 100% will be changed)
> > >
> > > ideally we should also:
> > >
> > > 4. Add metrics that available only via new API to the old API (because
> > > otherwise we force user interact with both API's)
> > >
> > > On Thu, Jan 30, 2020 at 12:35 PM Alexey Goncharuk
> > > <alexey.goncha...@gmail.com> wrote:
> > >>
> > >> Folks,
> > >>
> > >> I tried to re-read the whole thread and honestly got lost at the end
> :)
> > Do
> > >> we have a consensus (if yes, what are the steps?) or should we have a
> > call
> > >> as Maxim suggested?
> > >>
> > >> I think it is in our best interest to get this agreed upon fast to
> > release
> > >> AI 2.8 soon.
> >
> >
>
--
Best regards,
Andrey V. Mashenkov
