+1 for keeping a single git repo, too. -- Artem --
On Sat, Aug 22, 2015 at 10:03 PM, Sergi Vladykin <[email protected]> wrote: > +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 > > >
