Re: JIRA versions and multiple repos

Why are we trying to use separate repos for examples and native client? Is the main driver for this simply to use a different build tool than Gradle (at least for native client)? I would think a submodule could be ignored by Gradle and that submodule could have its own unrelated build too (cmake o

Re: JIRA versions and multiple repos

Btw, I've just confirmed that NiFi considers those subprojects (AKA separate communities). In fact ASF board asked them for that very clarification recently Thanks, Roman. On Thu, Jan 19, 2017 at 2:27 PM, Roman Shaposhnik wrote: > On Thu, Jan 19, 2017 at 2:23 PM, Anthony Baker wrote: >> >>> On

Re: JIRA versions and multiple repos

On Thu, Jan 19, 2017 at 2:23 PM, Anthony Baker wrote: > >> On Jan 19, 2017, at 1:01 PM, Roman Shaposhnik wrote: >> >> On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker > > wrote: >>> On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik wrote: On Thu, Jan 19

Re: JIRA versions and multiple repos

> On Jan 19, 2017, at 1:01 PM, Roman Shaposhnik wrote: > > On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker > wrote: >> >>> On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik wrote: >>> >>> On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith wrote: I wonder if we're trying

Re: JIRA versions and multiple repos

+1 to all the (excellent) points Udo made... Also to address this concern... > were not mentioning the versioning hell one does go through to get all projects on the same version This is exactly the reason for having a Maven BOM file. And, is exactly the reason the Spring IO Platform (http://pl

Re: JIRA versions and multiple repos

I don't know if I necessarily agree with this "lock-step" simplicity, every repo/project has the same version. That would become WAY too hard to vote on all the time... I can see scenarios where geode-server might add functionality and which clients don't need. Yes, we could version all the cl

Re: JIRA versions and multiple repos

I agree with @Dan on the geode-examples bit, but not for a modular Geode. So... It depends on whether you are releasing and publishing separate artifacts to Maven Central (or Bintray and the like) as features are developed/bugs are fixed (i.e. CI/CD), then it is necessary to distinguish by version

Re: JIRA versions and multiple repos

On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker wrote: > >> On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik wrote: >> >> On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith wrote: >>> I wonder if we're trying to overcomplicate things there. I don't see why >>> the geode-examples wouldn't use the same rel

Re: JIRA versions and multiple repos

> On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik wrote: > > On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith wrote: >> I wonder if we're trying to overcomplicate things there. I don't see why >> the geode-examples wouldn't use the same release schedule and version >> number as geode. >> >> The C++

Re: JIRA versions and multiple repos

+1 for keeping it Simple On Thu, Jan 19, 2017 at 11:59 AM, Swapnil Bawaskar wrote: > +1 > > On Thu, Jan 19, 2017 at 11:58 AM, Jacob Barrett > wrote: > > > I think I agree. We should try the same release cycle for all components > > until we find we can't. > > > > -Jake > > > > On Thu, Jan 19, 2

Re: JIRA versions and multiple repos

Do any of the users of what we call the C++ and .NET clients view them as libraries that provide an API? (As opposed to standalone applications.) If so, it would seem that they would expect the API libraries to move in step with the server releases. If the majority of the functionality in the C+

Re: JIRA versions and multiple repos

+1 On Thu, Jan 19, 2017 at 11:58 AM, Jacob Barrett wrote: > I think I agree. We should try the same release cycle for all components > until we find we can't. > > -Jake > > On Thu, Jan 19, 2017 at 11:21 AM Dan Smith wrote: > > > I wonder if we're trying to overcomplicate things there. I don't s

Re: JIRA versions and multiple repos

I think I agree. We should try the same release cycle for all components until we find we can't. -Jake On Thu, Jan 19, 2017 at 11:21 AM Dan Smith wrote: > I wonder if we're trying to overcomplicate things there. I don't see why > the geode-examples wouldn't use the same release schedule and ver

Re: JIRA versions and multiple repos

On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith wrote: > I wonder if we're trying to overcomplicate things there. I don't see why > the geode-examples wouldn't use the same release schedule and version > number as geode. > > The C++ and .NET clients are also somewhat tied to the version of geode > tha

Re: JIRA versions and multiple repos

I wonder if we're trying to overcomplicate things there. I don't see why the geode-examples wouldn't use the same release schedule and version number as geode. The C++ and .NET clients are also somewhat tied to the version of geode that they support. As long as we can stick to a regular release ca

Re: JIRA versions and multiple repos

What you're talking about makes sense -- but it is mechanics. What I'm talking about is a community composition. E.g. if we truly believe that communities of developers around, lets say core Java Geode and Native Client are non-overlapping (or there's very little overlap) we need to recognize this

Re: JIRA versions and multiple repos

Not sure if ASF has, or uses the same concept, but this could easily be handled with a GitHub "organization" encompassing 1 or more repos (for example... https://github.com/reactor). Of course, you could organize the source, and in particular, the Geode "modules" anyway you like, for example, as 1

Re: JIRA versions and multiple repos

On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker wrote: > Currently our JIRA versions look like this: > > 1.0.0-incubating.M1 > 1.0.0-incubating.M2 > 1.0.0-incubating.M3 > 1.1.0 > > That works great for the geode repo. However, what about the geode-examples > repo? I would like to set a ‘Fix vers

Re: JIRA versions and multiple repos

+1 sounds good On 1/19/17 09:02, John Blum wrote: On a slightly separate, but related note... One way of handling differing versions between potentially independently releasable artifacts/modules is to create a Maven BOM file. geode-examples are one thing, but when Geode becomes truly modular

Re: JIRA versions and multiple repos

On a slightly separate, but related note... One way of handling differing versions between potentially independently releasable artifacts/modules is to create a Maven BOM file. geode-examples are one thing, but when Geode becomes truly modular (in a sense that naturally bounded modules... Core, Q

JIRA versions and multiple repos

Currently our JIRA versions look like this: 1.0.0-incubating.M1 1.0.0-incubating.M2 1.0.0-incubating.M3 1.1.0 That works great for the geode repo. However, what about the geode-examples repo? I would like to set a ‘Fix version’ that matches the version in [1]. Since the repos can release ind