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
