It's the problem we are going to have with two distinctly different modules sharing the same project release cycle. The best we could do is branch release/v1.3 form the support/v1.2 branch until we are ready to release the breaking changes in the geode-native/develop branch.
-Jake 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 > >> > >
