On Fri, Aug 28, 2015 at 12:55 PM, Vladimir Ozerov <voze...@gridgain.com> wrote:
> 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. > What you describe sounds like a "mini-incubation" process inside the scope of Ignite: 1. The contributed subproject adds new value to users. 2. Code was closed source and in an undesirable state for public display. 3. There's going to be ongoing work to amend this code in order to make it fit for public. 4. During that time, the Ignite team warns users that the APIs may be volatile. 5. The ultimate goal is to stabilise the "semi-private" APIs. I don't think an API stability process needs to be defined here, after all this scenario is transitional. The fact that user-facing APIs are evolving is a sign that the project foundations are under heavy development. Wouldn't it be easier to version these modules with the 0.x version series? And then go through alpha, beta and RC stages up until version 1.0.0 – where the APIs are expected to be stable? Regards, *Raúl Kripalani* Apache Camel PMC Member & Committer | Enterprise Architect, Open Source Integration specialist http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani http://blog.raulkr.net | twitter: @raulvk