On Fri, Aug 28, 2015 at 05:14PM, Vladimir Ozerov wrote: > 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*
I think having those annotations aren't making developers more aware about potential compatibility problems, nor enforce any kind of policy mechanism around API compatibility. There's a plenty of examples in Hadoop (YARN in 2.4 and some other stuff before it) where incompatible changes were introduced in minor releases and had to be quickly corrected in a consequent patch release. What these annotations might help with is to quickly settle the argument that certain APIs shouldn't have been used in the first place, because they were @Evolving or otherwise. It's more like a UML diagram: if something goes wrong ppl have a common ground to find our who has screwed up and why; but it doesn't prevent the screw-up itself. Perhaps relying on public APIs as the only fully approved for 3rd party software developers is the only recourse in this case. Cos > 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. > > > > >
