+1 for a separate repo per client.
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771
On Mon, Jan 16, 2017 at 4:02 PM, Swapnil Bawaskar
wrote:
> +1 for a separate repo for each client.
>
> On Mon, Jan 16, 2017 at 12:25 PM, Joey McAllister
> wrote:
>
> > +1 to the se
+1 for a separate repo for each client.
On Mon, Jan 16, 2017 at 12:25 PM, Joey McAllister
wrote:
> +1 to the separate repo.
>
> I think it also makes sense—especially with independent release
> schedules—to keep the client documentation source in the client repo and
> build it as its own User Gu
+1 to the separate repo.
I think it also makes sense—especially with independent release
schedules—to keep the client documentation source in the client repo and
build it as its own User Guide, which we can host in its own section on
geode.apache.org/docs/.
On Mon, Jan 16, 2017 at 12:14 PM Udo Ko
+1 to separate client repos. Or at least some ability to independently
version client code for releases.
--Udo
On 1/16/17 11:56, Jacob Barrett wrote:
+1 for separate repo for sub-projects that would or could likely release
independently of the core project. I see this applying to most clients
+1 Separate repo for clients...Jake has valid point...
-Anil.
On Mon, Jan 16, 2017 at 12:07 PM, Michael William Dodge
wrote:
> +1 for at least a separate repo for the clients. Jake makes a good point
> about dependencies on different toolchains. I'm not sure whether that would
> merit have a s
+1 for at least a separate repo for the clients. Jake makes a good point about
dependencies on different toolchains. I'm not sure whether that would merit
have a separate repo for each platform's client, e.g., a repo for the Java
client, a repo for the C# client, etc. My instinct is to divide th
+1 for separate repo for sub-projects that would or could likely release
independently of the core project. I see this applying to most clients,
.net, c++, python, etc. It also cleanly separates out the build process
which is quite different between these projects. The native clients in
particular
I’m cautiously in favor of this idea. Allowing independent parts (geode,
geode-examples, geode-native) to progress and release at their own pace seems
like a good thing.
From a release perspective, I think each repo would have separate vote threads
and a section on our release page: http://ge
I would love a separate repo. Someone told me that wasn't an option. If
it's an option the let's make it so.
On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl wrote:
> Jake,
>
> Having all the clients in the repository is nice, however, has there been
> thought to have them in their own repository? No
Jake,
Having all the clients in the repository is nice, however, has there been
thought to have them in their own repository? Now that we are a TLP, we do
have that capability, as seen with the 'geode-examples' repository.
--Mark
On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer
wrote:
> -1 "geo
-1 "geode-native" directory name
+1 "geode-client" directory name
Maybe the directories for the different clients are by language, so we
omit the "geode" prefix i.e
geode-client/
c++,
net
java
python
If clients are in their own project, then the clients can be
independen
I was initially confused by using the term Native Client for our .NET and
C++ clients. If I'm a newcomer to GemFire, is it not more confusing to use
the term Native? I vote for switching our terminology to just GemFire +
Clients, where the clients can currently be written in Java, .NET, or C++.
Wh
.NET libraries can be written in any language that supports compilation to
CLI. This includes C++/CLI, C#, F#, etc. [1]. Your project need not be
written in the same language as the library. This is why I would suggest we
not name the client library after the language we used to write it.
[1] http
Let's try this again. Using the +1 mechanism for a multipart email is tough
so please include a comment on which part you are +1ing.
Also, I want to revise my suggestion to just call the directory
'geode-native' rather than 'geode-nativeclient'. Simply because I am lazy
and don't want to type the
Udo,
Not sure what part of my email you are +1ing.
-Jake
On Mon, Jan 16, 2017 at 8:45 AM Jacob Barrett wrote:
> On Mon, Jan 16, 2017 at 8:35 AM Michael William Dodge
> wrote:
>
> Given that the current source structure uses cpp and cli prefixes for the
> C++ and .NET clients, respectively, w
I'm not an expert at .NET development so please bear with me. In that world, is
CLI synonymous with C#? It seems that people who want a non-Java client for
Geode would be thinking of it in terms of programming language, which is why I
suggested csharp. It seems like people writing Geode clients
On Mon, Jan 16, 2017 at 8:35 AM Michael William Dodge
wrote:
> Given that the current source structure uses cpp and cli prefixes for the
> C++ and .NET clients, respectively, what about using cpp and cli for the
> directories, allowing any new .NET development to go into a separate
> directory (p
+1
There are discussions relating to the pure Java client. I think it would
fight right into the "geode-client" project.
--Udo
On 1/16/17 08:26, Jacob Barrett wrote:
One of the first things necessary to get NC merged into the the develop
branch is understanding where it will go under the cu
Given that the current source structure uses cpp and cli prefixes for the C++
and .NET clients, respectively, what about using cpp and cli for the
directories, allowing any new .NET development to go into a separate directory
(perhaps cs or csharp) without any additional moves?
Sarge
> On 16 J
+1 Makes sense to me
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771
On Mon, Jan 16, 2017 at 11:26 AM, Jacob Barrett wrote:
> One of the first things necessary to get NC merged into the the develop
> branch is understanding where it will go under the current geode
One of the first things necessary to get NC merged into the the develop
branch is understanding where it will go under the current geode project
structure.
The quick and obvious solution is adding a 'geode-nativeclient` subproject
and relocating all the NC sources into that directory.
Given that
21 matches
Mail list logo
