ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: API stability.
Date Fri, 28 Aug 2015 14:18:53 GMT
Raul,

Yes, separate versioning could be a solution. But 0.x and "RC" versions
usually distract users because they think that the product is not yet
stable enough to be used.in production. In our case product is fine, public
API is fine, but only extensions API is not good enough. And it can
potentially affect only very small subset of advanced users who are
developing Ignite extensions.

On Fri, Aug 28, 2015 at 4:31 PM, Raul Kripalani <raul@evosent.com> wrote:

> On Fri, Aug 28, 2015 at 12:55 PM, Vladimir Ozerov <vozerov@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
>

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