+1 for keeping a single git repo. No reason to add complexity to project structure.
Sergi 2015-08-22 21:51 GMT+03:00 Raul Kripalani <[email protected]>: > On Sat, Aug 22, 2015 at 7:17 PM, Konstantin Boudnik <[email protected]> > 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 > experience. > > 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 >
