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

Reply via email to