Jacob - Ah, sorry to hear that. On Thu, May 4, 2017 at 2:09 PM, Jacob Barrett <jbarr...@pivotal.io> wrote:
> John, I wish we could do that but Apache would require that geode-native be > a fully qualified sub-project with all the headache that goes with that to > "release" separately. > > > On Thu, May 4, 2017 at 11:35 AM John Blum <jb...@pivotal.io> wrote: > > > A good reason to use separate repos. Individual components of Geode, > > especially clear boundaries like Native Client, *Gfsh*, or Pulse, etc, > > should be separately and independently releasable to provide a smoother > > release cadence based on velocity and community need. > > > > Then, using a Maven "BOM", you can tie all the independent (yet > compatible) > > versions together in 1 cohesive collection of artifacts for a particular > > release of Geode. > > > > You think all the SD modules in the "release train" have a same version? > > No! > > > > Case in point... > > > > > > https://github.com/spring-projects/spring-data-build/ > blob/1.9.3.RELEASE/bom/pom.xml#L21-L146 > > > > They all have the same "symbolic" version though... > > > > > > https://github.com/spring-projects/spring-data-build/ > blob/1.9.3.RELEASE/bom/pom.xml#L6-L7 > > > > Which is what other projects (e.g. *Spring Boot*) use to pull in the SD > > train... > > > > > > https://github.com/spring-projects/spring-boot/blob/v1. > 5.3.RELEASE/spring-boot-dependencies/pom.xml#L158 > > > > > > https://github.com/spring-projects/spring-boot/blob/v1. > 5.3.RELEASE/spring-boot-dependencies/pom.xml#L2088-L2094 > > > > While we don't typically release individual SD modules (though, it has > been > > known to occur [1]), we could. But, we try to keep all modules in sync > > with the train since all have a common core (*Spring Framework* / *Spring > > Data Commons*), but they have all different versions. Many other open > > source projects operate the same way... Reactor. > > > > $0.02 > > > > -John > > > > > > [1] > > > > https://github.com/spring-projects/spring-data-gemfire/ > tree/1.8.4.RELEASE-PATCH01 > > > > > > On Thu, May 4, 2017 at 11:23 AM, Anthony Baker <aba...@pivotal.io> > wrote: > > > > > Let’s say we release geode-native along with geode 1.2. When it comes > > > time to release 1.3 (and geode-native is not yet ready) we would be > > > creating release branches from: > > > > > > geode: develop > > > geode-example: develop > > > geode-native: release/v1.2.0 > > > > > > Anthony > > > > > > > On May 4, 2017, at 11:16 AM, Jacob Barrett <jbarr...@pivotal.io> > > wrote: > > > > > > > > I don't see how they are different branches? If geode-Native has > > > release/1.2 and Geode has release/1.2? > > > > > > > > Sent from my iPhone > > > > > > > >> On May 4, 2017, at 10:21 AM, Anthony Baker <aba...@pivotal.io> > wrote: > > > >> > > > >> I think it’s confusing to cut a release from different branches for > > > geode, geode-examples, and geode-native but I don’t have a better idea. > > > >> > > > >> +0 > > > >> > > > >> Anthony > > > >> > > > >>> On May 4, 2017, at 7:29 AM, Jacob Barrett <jbarr...@pivotal.io> > > wrote: > > > >>> > > > >>> All, > > > >>> > > > >>> I want to start the discussion on releasing Geode Native C++ and > .NET > > > >>> clients with the next or near future Geode release. > > > >>> > > > >>> There are a few house keeping items left in the source release JIRA > > > [1]. It > > > >>> would be great to get some help completing these tasks. > > > >>> > > > >>> If we start with a source only release, which Geode release should > we > > > >>> target? Since it is "adding feature" it seems it makes the most > sense > > > to do > > > >>> it as part of a minor release, say 1.2. > > > >>> > > > >>> To throw a little wrench in it all. There are some serious changes > > > coming > > > >>> with [2] conversion to std::shared_ptr, [3] removal of all globals, > > [4] > > > >>> replacing all non-standard concurrency methods. These changes won't > > be > > > >>> compatible with sources written against previous releases of > > > geode-native, > > > >>> thus suggesting they will need a major rev shortly. My suggestion > > > would be > > > >>> to cut a release branch now on geode-native for 1.2 and get it > ready > > > for > > > >>> source release. Backport any changes on the release branch to > > develop. > > > That > > > >>> leaves develop open for marching forward with what would be a 2.0 > set > > > of > > > >>> sources. Any release of Geode 1.x would just include the > geode-native > > > >>> release/1.x branches until Geode 2.0. > > > >>> > > > >>> Thoughts and feedback? > > > >>> > > > >>> [1] https://issues.apache.org/jira/browse/GEODE-1416 > > > >>> [2] https://issues.apache.org/jira/browse/GEODE-2807 > > > >>> [3] https://issues.apache.org/jira/browse/GEODE-2729 > > > >>> [4] https://issues.apache.org/jira/browse/GEODE-2493 > > > >>> > > > >>> -Jake > > > >> > > > > > > > > > > > > -- > > -John > > john.blum10101 (skype) > > > -- -John john.blum10101 (skype)
