ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Kripalani <ra...@apache.org>
Subject Re: New module for C++/.Net integration.
Date Sat, 22 Aug 2015 18:51:13 GMT
On Sat, Aug 22, 2015 at 7:17 PM, Konstantin Boudnik <cos@apache.org> wrote:

> Why do you want to release a C++ client separately from the platform? How
> you're going to guarantee the compatibility between the two? Who and who
> will
> be doing the pretty complex system testing in this case?

Actually, citing the announcement email:

> These are not basic client APIs, but rather is a full-blown in-memory data
> fabric for .NET and C++ users.

I interpret that the donation has a wider scope than just client APIs. My
impression is that they're actually interop layers bridging the target
language (C++/.NET) with Ignite Java through a JNI interface. Probably
complex plumbing that'll be subject to bugfixing and evolution of it's own,
regardless of the release cycle of Ignite Java as a platform. Of course we
can couple both tightly, but if we discover a nasty regression in the .NET
interop layer (which does not affect Ignite Java nor C++), and we want to
do an emergency release, it would be pretty useless to release everything
in a monolithic block. Hence my reasoning for allowing loose evolution on
the micro semver level, but with simultaneous releases on the major and
micro levels. Kinda like what Eclipse does (simultaneous releases +
independent bugfixing until the next simultaneous release).

Just my 2 cent, though!

Let's not put the cart before the horse. Let's have the code transitioned
> first, ran through a couple of releases and then we'll see if separation
> is so
> beneficial for anyone in the community. Before that - it's just a moot
> academic
> reflection.

Yeah, that's OK too. I appreciate diversity of options when taking
decisions like this, hence me raising the Git subtree option to the
community (as it had not been discussed) and providing my rationale. Only
time will prove which option was most comfortable, and it's never too late
to change.

But really, Git subtrees are not that hard to set up and maintain, in my


*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

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