New module for C++/.Net integration.

[Vladimir Ozerov]

Igniters,

I am starting migration of C++/.Net integration modules donated by GridGain
to Ignite. I am going to put all that stuff, including Java classes, .Net
classes and .cpp/.h files in a new module.

In GridGain we first named this stuff "clients" and later "interop". But
there are several problems with these namings:
1) These are not clients, but rather fully-fledged Ignite nodes operated
through non Java-platform.
2) "interop" is a jargon and do not give user clear understanding on what
API is about.

Batter name for that module which comes to my mind is "platform". And
following our standard naming conventions for Java classes there will be
something like "PlatformDotNetConfiguration", "PlatformProcessor", etc..

Any more ideas on how to name this stuff?

Vladimir.

[Gianfranco Murador]

Hi Vladimir,
 I believe that the naming convention is fine (I speak as a user), but
 could we call the module Ignite4net or IgniteNetModule ?
The only thing to consider is that the interfaces in .NET are always named
with the letter "I " to the first position ( IService for example ).
Regards,
 Gianfranco

2015-08-21 15:50 GMT+02:00 Vladimir Ozerov <[hidden email]>:

> Igniters,
>
> I am starting migration of C++/.Net integration modules donated by GridGain
> to Ignite. I am going to put all that stuff, including Java classes, .Net
> classes and .cpp/.h files in a new module.
>
> In GridGain we first named this stuff "clients" and later "interop". But
> there are several problems with these namings:
> 1) These are not clients, but rather fully-fledged Ignite nodes operated
> through non Java-platform.
> 2) "interop" is a jargon and do not give user clear understanding on what
> API is about.
>
> Batter name for that module which comes to my mind is "platform". And
> following our standard naming conventions for Java classes there will be
> something like "PlatformDotNetConfiguration", "PlatformProcessor", etc..
>
> Any more ideas on how to name this stuff?
>
> Vladimir.
>

[dsetrakyan]

On Fri, Aug 21, 2015 at 6:50 AM, Vladimir Ozerov <[hidden email]>
wrote:

I am starting migration of C++/.Net integration modules donated by
> GridGain to Ignite. I am going to put all that stuff, including Java
> classes, .Net classes and .cpp/.h files in a new module.
>

Vladimir, shouldn't we have separate modules for .NET and C++? I don't
understand why put them in one module.

[Raul Kripalani]

Have you considered the possibility of hosting these codebases in separate
Git repos?

I don't think it's a good idea to mix so many technologies within a single
source tree.

You can have a look at how ActiveMQ do it with their C++ [1] and .NET [2]
clients – one repo for each technology to keep the build and project
lifecycles sane.

[1] http://activemq.apache.org/cms/source.html
[2] http://activemq.apache.org/nms/source.html

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

On Fri, Aug 21, 2015 at 2:50 PM, Vladimir Ozerov <[hidden email]>
wrote:

> Igniters,
>
> I am starting migration of C++/.Net integration modules donated by GridGain
> to Ignite. I am going to put all that stuff, including Java classes, .Net
> classes and .cpp/.h files in a new module.
>
> In GridGain we first named this stuff "clients" and later "interop". But
> there are several problems with these namings:
> 1) These are not clients, but rather fully-fledged Ignite nodes operated
> through non Java-platform.
> 2) "interop" is a jargon and do not give user clear understanding on what
> API is about.
>
> Batter name for that module which comes to my mind is "platform". And
> following our standard naming conventions for Java classes there will be
> something like "PlatformDotNetConfiguration", "PlatformProcessor", etc..
>
> Any more ideas on how to name this stuff?
>
> Vladimir.
>

[Vladimir Ozerov]

GIanfranco,
The question was more about module naming. Surely, we follow .Net naming
conventions in .Net part. :-)

On Fri, Aug 21, 2015 at 5:59 PM, Gianfranco Murador <
[hidden email]> wrote:

> Hi Vladimir,
>  I believe that the naming convention is fine (I speak as a user), but
>  could we call the module Ignite4net or IgniteNetModule ?
> The only thing to consider is that the interfaces in .NET are always named
> with the letter "I " to the first position ( IService for example ).
> Regards,
>  Gianfranco
>
> 2015-08-21 15:50 GMT+02:00 Vladimir Ozerov <[hidden email]>:
>
> > Igniters,
> >
> > I am starting migration of C++/.Net integration modules donated by
> GridGain
> > to Ignite. I am going to put all that stuff, including Java classes, .Net
> > classes and .cpp/.h files in a new module.
> >
> > In GridGain we first named this stuff "clients" and later "interop". But
> > there are several problems with these namings:
> > 1) These are not clients, but rather fully-fledged Ignite nodes operated
> > through non Java-platform.
> > 2) "interop" is a jargon and do not give user clear understanding on what
> > API is about.
> >
> > Batter name for that module which comes to my mind is "platform". And
> > following our standard naming conventions for Java classes there will be
> > something like "PlatformDotNetConfiguration", "PlatformProcessor", etc..
> >
> > Any more ideas on how to name this stuff?
> >
> > Vladimir.
> >
>

[Vladimir Ozerov]

Dmitriy, Raul,

In current GridGain codebase we keep everything in a single repository and
a single module. Here is why:
1) We have 4 distinct parts: Java supporting code, common CPP/JNI layer
which depends on Java, .Net implementation which depends on Java and JNI,
CPP platform implementation which depends on Java and JNI. And very often
it is necessary to update several of  them in scope of a single ticket. It
will be a nightmare to update them in different repos - tons of patches
and/or pull requests.
2) We have them in a single module because we are Maven-based project. From
.Net/CPP user perspective it doesn't matter whether C++ code they are going
to build is located inside $IGNITE_HOME/modules/platform/src/main/cpp or
$IGNITE_HOME/modules/platform_cpp/src. I do not see what are advantages of
shuffling non-Java files a bit differently across the repo. "src/main/*java*"
folder in Maven was "invented" for such cases as well.

Vladimir.


On Fri, Aug 21, 2015 at 6:33 PM, Raul Kripalani <[hidden email]> wrote:

> Have you considered the possibility of hosting these codebases in separate
> Git repos?
>
> I don't think it's a good idea to mix so many technologies within a single
> source tree.
>
> You can have a look at how ActiveMQ do it with their C++ [1] and .NET [2]
> clients – one repo for each technology to keep the build and project
> lifecycles sane.
>
> [1] http://activemq.apache.org/cms/source.html
> [2] http://activemq.apache.org/nms/source.html
>
> 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
>
> On Fri, Aug 21, 2015 at 2:50 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Igniters,
> >
> > I am starting migration of C++/.Net integration modules donated by
> GridGain
> > to Ignite. I am going to put all that stuff, including Java classes, .Net
> > classes and .cpp/.h files in a new module.
> >
> > In GridGain we first named this stuff "clients" and later "interop". But
> > there are several problems with these namings:
> > 1) These are not clients, but rather fully-fledged Ignite nodes operated
> > through non Java-platform.
> > 2) "interop" is a jargon and do not give user clear understanding on what
> > API is about.
> >
> > Batter name for that module which comes to my mind is "platform". And
> > following our standard naming conventions for Java classes there will be
> > something like "PlatformDotNetConfiguration", "PlatformProcessor", etc..
> >
> > Any more ideas on how to name this stuff?
> >
> > Vladimir.
> >
>

[Raul Kripalani]

On Fri, Aug 21, 2015 at 4:47 PM, Vladimir Ozerov <[hidden email]>
wrote:

> 1) We have 4 distinct parts: Java supporting code, common CPP/JNI layer
> which depends on Java, .Net implementation which depends on Java and JNI,
> CPP platform implementation which depends on Java and JNI. And very often
> it is necessary to update several of  them in scope of a single ticket. It
> will be a nightmare to update them in different repos - tons of patches
> and/or pull requests.
>

I see what you mean; if I understood, it's a matter of (1) convenience and
(2) being able to push commits that contain all changes to support a given
functionality across all platforms.

Have you considered Git Subtrees? With that approach I think you can get
the best of both worlds (separation in different Git repos, and mapping of
"satellite" repos into directories of a core repo). In my mind, we would be
having 3 repos:

* Repo "ignite" => Ignite (Java) + CPP/JNI layer. This is essentially
Ignite + the contract and interop layer for other languages to leverage
Ignite.
* Repo "ignite-cpp" => platform implementation for Ignite in C++.
* Repo "ignite-dotnet" =>  platform implementation for .NET.

The ignite repo would map the ignite-cpp and ignite-dotnet repos into the
source tree via git subtree.

Considerations:

* Folks only wanting to interact only with ignite's Java code would not
need to fetch the ignite-cpp and ignite-dotnet repos. Most people will fall
in this category, I assume.
* Git subtree automatically takes care of splitting commits that span
multiple repos, for them to be applied individually to each repo.
* Tagging commits with JIRA ticket ids allow us to group commits across a
number of repos under the "umbrella" of a single functionality.

For those people who are not familiar with Git subtrees, this is a nice
walkthrough: [1].

[1] https://medium.com/@v/git-subtrees-a-tutorial-6ff568381844

*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

[Konstantin Boudnik-2]

What exactly are you trying to solve ? To safe a few hundred kilos of source code not being fetched, but to push the complexity of the build, dependencies, and testing elsewhere? What's the clear win if you have separate repos?

Cos


On August 22, 2015 5:28:58 AM PDT, Raul Kripalani <[hidden email]> wrote:

>On Fri, Aug 21, 2015 at 4:47 PM, Vladimir Ozerov <[hidden email]>
>wrote:
>
>> 1) We have 4 distinct parts: Java supporting code, common CPP/JNI
>layer
>> which depends on Java, .Net implementation which depends on Java and
>JNI,
>> CPP platform implementation which depends on Java and JNI. And very
>often
>> it is necessary to update several of  them in scope of a single
>ticket. It
>> will be a nightmare to update them in different repos - tons of
>patches
>> and/or pull requests.
>>
>
>I see what you mean; if I understood, it's a matter of (1) convenience
>and
>(2) being able to push commits that contain all changes to support a
>given
>functionality across all platforms.
>
>Have you considered Git Subtrees? With that approach I think you can
>get
>the best of both worlds (separation in different Git repos, and mapping
>of
>"satellite" repos into directories of a core repo). In my mind, we
>would be
>having 3 repos:
>
>* Repo "ignite" => Ignite (Java) + CPP/JNI layer. This is essentially
>Ignite + the contract and interop layer for other languages to leverage
>Ignite.
>* Repo "ignite-cpp" => platform implementation for Ignite in C++.
>* Repo "ignite-dotnet" =>  platform implementation for .NET.
>
>The ignite repo would map the ignite-cpp and ignite-dotnet repos into
>the
>source tree via git subtree.
>
>Considerations:
>
>* Folks only wanting to interact only with ignite's Java code would not
>need to fetch the ignite-cpp and ignite-dotnet repos. Most people will
>fall
>in this category, I assume.
>* Git subtree automatically takes care of splitting commits that span
>multiple repos, for them to be applied individually to each repo.
>* Tagging commits with JIRA ticket ids allow us to group commits across
>a
>number of repos under the "umbrella" of a single functionality.
>
>For those people who are not familiar with Git subtrees, this is a nice
>walkthrough: [1].
>
>[1] https://medium.com/@v/git-subtrees-a-tutorial-6ff568381844
>
>*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

[Raul Kripalani]

On Sat, Aug 22, 2015 at 5:56 PM, Konstantin Boudnik <[hidden email]> wrote:

> What exactly are you trying to solve ? To safe a few hundred kilos of
> source code not being fetched, but to push the complexity of the build,
> dependencies, and testing elsewhere? What's the clear win if you have
> separate repos?


Nah, not really the download size. That's secondary.

You think putting each project in its own repo and linking them via Git
subtrees is the more complex than keeping it all in one repo?! I think
that's an early conclusion. There are things we haven't talked about, e.g.
project lifecycles, release lifecycles, continuous integration, releases
for different processor architectures and/or OS (C++), etc. In reality,
source code structure should go hand-in-hand with the type of organization
we pursue, so we should discuss that first.

Hosting each project in a separate repo (and linking them via Git subtrees)
is beneficial for several reasons. Off the top of my head:

* Independent – but related – lifecycles for each subproject. While all
projects are intertwined, being able to release .NET, CPP, Ignite Java
separately is fundamental for bugfixing. If the community hasn't talked
about this, now's a good idea to define a versioning policy and/or scheme.
Can each implementation evolve separately, i.e. with independent micro
versions (semver) if bugfixes are to be released ASAP for just a single
platform? Or do we keep all versions in sync and wait for a simultaneous
release? (à la Eclipse).

* Converging different build systems, each with its own release system, for
a different technology, inside the same repo may be confusing and
counter-intuitive for users.

* If you want to fix a .NET or CPP bug, and want to create a branch
exclusively for that platform, I don't see why you should be branching all
off Ignite for all platforms.

* Similarly, if we are allowing independent (but related) lifecycles for
each part, I don't see why a tag for a .NET bugfix, e.g.
ignite-dotnet-1.4.5 release should contain all of Ignite including CPP and
Java, especially if those versions are still on 1.4.3. That's plain
confusing, and with Git one cannot tag a specific region of the tree.

Now from my personal experience: once you start cramming up several
heterogeneous projects that satisfy conditions like...

(a) targeting different user bases / consumers (albeit some organisations
may use all 3 simultaneously).
(b) using different technologies and programming languages.
(c) may evolve with slightly different (but related) lifecycles.
(d) requiring different build systems with distinct CI setups each (for
.NET you'll need a Windows node on TeamCity).
(e) different release systems (e.g. for CPP you'll need to likely an
artifact per architecture).
(f) attracting contributors with different skills (few people are
proficient enough to work on Java, .NET and C++ simultaneously and
effectively).

... you're likely more inclined towards separating the code bases (and
linking them) rather than hosting everything inside one big repo.

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

[Konstantin Boudnik-2]

On Sat, Aug 22, 2015 at 06:31PM, Raul Kripalani wrote:

> On Sat, Aug 22, 2015 at 5:56 PM, Konstantin Boudnik <[hidden email]> wrote:
>
> > What exactly are you trying to solve ? To safe a few hundred kilos of
> > source code not being fetched, but to push the complexity of the build,
> > dependencies, and testing elsewhere? What's the clear win if you have
> > separate repos?
>
>
> Nah, not really the download size. That's secondary.
>
> You think putting each project in its own repo and linking them via Git
> subtrees is the more complex than keeping it all in one repo?! I think
> that's an early conclusion. There are things we haven't talked about, e.g.
> project lifecycles, release lifecycles, continuous integration, releases
> for different processor architectures and/or OS (C++), etc. In reality,
> source code structure should go hand-in-hand with the type of organization
> we pursue, so we should discuss that first.

I am a very empirical guy. I know for a fact from a few pretty bad experiences
in the past that the split like that - unless _absolutely_ demanded by some
forces outside of the development (e.g. legal requirements) - adds nothing but
a massive headache. Thank you for bringing up release engineering, CI and all
other things. Because that's exactly where the nightmares will be coming from
down the road.

> Hosting each project in a separate repo (and linking them via Git subtrees)
> is beneficial for several reasons. Off the top of my head:
>
> * Independent – but related – lifecycles for each subproject. While all
> projects are intertwined, being able to release .NET, CPP, Ignite Java
> separately is fundamental for bugfixing. If the community hasn't talked
> about this, now's a good idea to define a versioning policy and/or scheme.
> Can each implementation evolve separately, i.e. with independent micro
> versions (semver) if bugfixes are to be released ASAP for just a single
> platform? Or do we keep all versions in sync and wait for a simultaneous
> release? (à la Eclipse).

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?

> * Converging different build systems, each with its own release system, for
> a different technology, inside the same repo may be confusing and
> counter-intuitive for users.

Just as a data point: I am a Bigtop guy. We have build a whole ecosystem and a
framework to mitigate the complexities coming from what you just described.
But we had to do it because we deal with 20+ different projects, running by
different people. Why someone would like to create the hurdle like that for
himself - is really beyond me.

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.

Best,
  Cos

> * If you want to fix a .NET or CPP bug, and want to create a branch
> exclusively for that platform, I don't see why you should be branching all
> off Ignite for all platforms.
>
> * Similarly, if we are allowing independent (but related) lifecycles for
> each part, I don't see why a tag for a .NET bugfix, e.g.
> ignite-dotnet-1.4.5 release should contain all of Ignite including CPP and
> Java, especially if those versions are still on 1.4.3. That's plain
> confusing, and with Git one cannot tag a specific region of the tree.
>
> Now from my personal experience: once you start cramming up several
> heterogeneous projects that satisfy conditions like...
>
> (a) targeting different user bases / consumers (albeit some organisations
> may use all 3 simultaneously).
> (b) using different technologies and programming languages.
> (c) may evolve with slightly different (but related) lifecycles.
> (d) requiring different build systems with distinct CI setups each (for
> .NET you'll need a Windows node on TeamCity).
> (e) different release systems (e.g. for CPP you'll need to likely an
> artifact per architecture).
> (f) attracting contributors with different skills (few people are
> proficient enough to work on Java, .NET and C++ simultaneously and
> effectively).
>
> ... you're likely more inclined towards separating the code bases (and
> linking them) rather than hosting everything inside one big repo.
>
> 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

[Raul Kripalani]

On Sat, Aug 22, 2015 at 7:17 PM, Konstantin Boudnik <[hidden email]> 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

[Sergi]

+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 <[hidden email]>:

> On Sat, Aug 22, 2015 at 7:17 PM, Konstantin Boudnik <[hidden email]>
> 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
>

[Artem Shutak]

+1 for keeping a single git repo, too.

-- Artem --

On Sat, Aug 22, 2015 at 10:03 PM, Sergi Vladykin <[hidden email]>
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 <[hidden email]>:
>
> > On Sat, Aug 22, 2015 at 7:17 PM, Konstantin Boudnik <[hidden email]>
> > 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
> >
>