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 >
