The thread I referenced discussed the topic of different release cycles for our repos. The ASF viewpoint is that if you have separate release cycles for different repos you have an independent subproject. And a subproject implies a different community and PMC.
Anthony > On Oct 23, 2017, at 10:17 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > Anthony, I don't see the relevance of the thread you mention. Can you > please explain how a discussion on tagging releases in JIRA relates to this > discussion? > > On Mon, Oct 23, 2017 at 10:06 AM Anthony Baker <aba...@pivotal.io> wrote: > >> Before we start this thread again, please read [1]. >> >> Anthony >> >> [1] >> http://mail-archives.apache.org/mod_mbox/geode-dev/201701.mbox/%3cdb3f0e86-1d8f-4acc-8323-fe8c135b3...@pivotal.io%3e >> < >> http://mail-archives.apache.org/mod_mbox/geode-dev/201701.mbox/%3cdb3f0e86-1d8f-4acc-8323-fe8c135b3...@pivotal.io%3E >>> >> >> >>> On Oct 23, 2017, at 9:51 AM, Addison Huddy <ahu...@pivotal.io> wrote: >>> >>> I agree with Jake that the examples directory should not be part of our >>> official releases. They should be a light-weight entry point to our >>> community, meaning they should be easy to create, modify, and use. While >>> counter-intuitive, in this case, a less official approach to our examples >>> will yield fresher and more helpful examples. >>> >>> On Mon, Oct 23, 2017 at 9:18 AM, Jacob Barrett <jbarr...@pivotal.io> >> wrote: >>> >>>> On Fri, Oct 20, 2017 at 6:02 PM Dan Smith <dsm...@pivotal.io> wrote: >>>> >>>>> However I do think we should be compiling (and hopefully running!) >>>>> these examples so that they don't rot over time. Especially since I >>>>> believe we are still evolving the native API with breaking changes and >>>>> have not actually managed a release for the native code yet? >>>>> >>>> >>>> If someone in the community has the bandwidth to setup a windows jenkins >>>> build the system requirements and instructions are in the geode-native >>>> README.md. There is a very specific set of toolkit needed to build Geode >>>> Native. After getting Native building you will need to find a way to >> update >>>> the csproj files with the path to the Apache.Geode.dll before building >> the >>>> examples solution. I would recommend CMake for that process but a simple >>>> sed replacement works too. >>>> >>>> One option if it is too hard to automate the build of these things in >>>>> geode-examples is that we could put them into geode-native until we >>>>> actually release geode-native. >>>> >>>> >>>> I think it is just fine keeping them where they are. I have very strong >>>> reservations about treating the geode-examples repo as some blessed and >>>> released repository. If it is that strongly coupled with the Geode >> release >>>> then it should have never been moved to its own repo. Geode Native was >> put >>>> in its own repo to allow Geode Native to develop and release on an >>>> independent cycle than that of the Geode server and java client. The >> same >>>> rational was used to support the creation of geode-examples repo. This >>>> should be a living and breathing ground for community based examples. If >>>> ware going to treat it as product and product that is tied to the geode >>>> repo then those components should be moved to the geode repo. >>>> >>>> If the community disagrees then I will gladly move the native examples >> out >>>> of geode-examples. >>>> >>>> -Jake >>>> >> >>
