Dima, I'm not suggesting doing this, they are already not stable. For example, take a look at IgniteCacheObjectProcessor. This is a component which can be injected through plugins, thus it is "semi-public". However, it is under heavy changes and if some unlucky guy is to implement a plugin using this processor, he will face compilation errors with each new Ignite release.
My suggestion is to define policies for things like that. One of possible solutions - is to annotate APIs so that developers are aware of potential problems. One more example from Hadoop: 1) org.apache.hadoop.fs.FileSystem: @Public, @Stable 2) org.apache.hadoop.fs.AbstractFileSystem: @Public, *@Evolving* Vladimir. On Fri, Aug 28, 2015 at 4:20 PM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > Vladimir, > > Are you suggesting making semi-private APIs not stable? In that case, what > is the recourse for the current users? > > D. > > On Fri, Aug 28, 2015 at 2:55 PM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > > > Igniters, > > > > We have several types of APIs: > > 1) Public - intended for Ignite users. E.g.: IgniteCache. > > 2) Private - used only by Ignite developers. E.g.: almost everything > inside > > "org.apache.ignite.internal". > > 3) Semi-private - is not expected to be used by users, but can be used by > > 3rd-party developers. E.g.: PluginProvider. > > > > I'd like to propose defining "stability" for p.3 type of APIs. That is. > if > > someone develops Ignite extensions, he might need to know what is the > > probability of breaking change of that API. Nice example of such approach > > is Hadoop APIs. > > > > The reason why I started thinking about it is "platforms" migration from > > GridGain to Ignite. Currently our platforms API are far from ideal from > > external developer's point of view. This was not a problem in GridGain > > since the code was private, but it can become a problem in open-sourced > > Ignite. > > And instead of spending time on making APIs nice and clean I'd like to > make > > platforms work first. During this transition time it would be nice to > mark > > relevant APIs as "unstable" so that potential 3rd-party devs will be > aware > > of a risk when using them. > > > > Thoughts? > > > > Vladimir. > > >
