ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <agoncha...@apache.org>
Subject [DISCUSS] Public API deprecation rules
Date Wed, 05 Feb 2020 19:36:01 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message