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 number to avoid collisions/conflicts and e able to consume the bits (which is much easier than anything else, to do from MC, when developing). However, when you start talking about Native Client vs. the geode-examples; those are 2 different animals! I would even go so far as to say the geode-examples could (and probably, should) live outside of the (core) Geode codebase. They do not need to be released with the product. They can, be based on a particular (curated/harmonized) set of Geode dependencies (using the Maven BOM I described earlier; Spring Data Examples does this, for instance, but SD Examples are not part of the SD Release Train). Or, how about, if I come up with another example, perhaps one based on a customer UC that highlights Geode is some particular way, addressing a very common, very important problem, which is independent of the Geode codebase, why should anyone have to wait for another Geode release for this example to be pushed? Like the Native Client, arguably, Spring Data Geode is closely tied to Apache Geode, yet releases separately and independently, at it's own cadence. That is also not to say 1 does not affect the other (Apache Geode most certainly affects SDG), but ironically, even though both are OSS projects with nearly the same "community" behind them, they are separate. On Thu, Jan 19, 2017 at 1:01 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote: > On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker <aba...@pivotal.io> wrote: > > > >> On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik <ro...@shaposhnik.org> > wrote: > >> > >> On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith <dsm...@pivotal.io> 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 > >>> that they support. As long as we can stick to a regular release > cadence, It > >>> seems like those clients couldn't also follow the same release > schedule and > >>> version numbers. > >> > >> Huge +1 to the above! > >> > >> Thanks, > >> Roman. > > > > > > Here’s a few examples of ASF projects with multiple repos for reference: > > > > - ActiveMQ > > https://github.com/apache?utf8=✓&q=activemq&type=&language= > > https://issues.apache.org/jira/secure/BrowseProjects.jspa#11160 > > - Nifi > > https://github.com/apache?utf8=✓&q=nifi&type=&language= > > https://issues.apache.org/jira/secure/BrowseProjects.jspa#13460 > > > > I agree that semi-coordinated releases from a single project community > make > > sense—these are not independent things. Using lock-step versioning means > > we release everything together, even for patch releases right? And I’m > > assuming we would be doing separate release VOTE threads per repo. > > An interesting thing to note is that despite multiple repos they still > release > a single source artifact: > https://www.apache.org/dist/activemq/5.13.5/ > https://www.apache.org/dist/nifi/1.1.1/ > > Thanks, > Roman. > -- -John john.blum10101 (skype)
