Hello, I have two notes
> * Allow to deprecate the old APIs even when new APIs are marked with > @IgniteExperimental to explicitly notify users that the new APIs are available I think the main reason is not «notify users that new APIs are available», but «Notify users that old APIs will be removed in the next major release AND new APIs are available» > @IgniteExperimental [3] which marks APIs which are yet not stable, dangerous, > partially implemented or are allowed to be changed in a future. It seems too wide definition of «experimental API» I think we can’t release «dangerous» API. For me, `@IgniteExperimental` should mark public APIs that can be slightly improved or changed in the next minor release. > 6 февр. 2020 г., в 13:23, Andrey Gura <ag...@apache.org> написал(а): > > One comment about first choice. > > The formulation has one issue from my point of view: Never deprecate > the old APIs unless the new APIs are stable *and released* without > @IgniteExperimental. > > Actually we can introduce new stable API and deprecate old API at the > same time without releasing of new API. For example > IgniteCache.withAsync() method was deprecated and new methods > xxxAsync() were added at the same time as stable alternative. In this > case we didn't collect users' feedback because negative users' > feedback about withAsync() was a driver for this change. > > On Thu, Feb 6, 2020 at 6:26 AM Denis Magda <dma...@apache.org> wrote: >> >> The justification and choices look crystal clear to me. >> >> - >> Denis >> >> >> On Wed, Feb 5, 2020 at 1:36 PM Alexey Goncharuk <agoncha...@apache.org> >> wrote: >>> >>> Igniters, >>> >>> We would like to add some formal requirements to the API deprecation >>> process. So far the API deprecation was more like intuitive-driven which >>> recently led to some disagreement and delaying the AI 2.8 release [1][2]. >>> >>> During the discussion [1] we agreed to add an >>> annotation @IgniteExperimental [3] which marks APIs which are yet not >>> stable, dangerous, partially implemented or are allowed to be changed in a >>> future. The reason to release such APIs is to expose the APIs to users and >>> collect feedback on the usability and possible bugs. >>> >>> The argument we did not manage to resolve is whether we are allowed to >>> deprecate the old APIs _before_ the new ones get stable and get released >>> without @IgniteExperimental annotation. We decided to resolve the >>> uncertainty with a vote. >>> >>> The vote we are going to have is reduced to two choices so far: >>> * Never deprecate the old APIs unless the new APIs are stable and released >>> without @IgniteExperimental. The old APIs javadoc may be updated with a >>> reference to new APIs to encourage users to evaluate new APIs >>> * Allow to deprecate the old APIs even when new APIs are marked >>> with @IgniteExperimental to explicitly notify users that the new APIs are >>> available >>> >>> Nikolay, Andrey, please let us know if we should correct the choices >>> articulation or add another option for the vote. >>> >>> --AG >>> >>> [1] >>> http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-td45146.html >>> [2] >>> http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-td45146.html >>> [3] https://issues.apache.org/jira/browse/IGNITE-12559
