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
> >>
>
>

Reply via email to