For clarification... 1. SBDG 1.1 is the "*current*" development line (on <https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17> master <https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17> [1]); SBDG 1.2 is *not* yet in development. 2. SBDG 1.1 is at RC1 <https://github.com/spring-projects/spring-boot-data-geode/releases> [2]. 3. SBDG 1.1 is based on Spring Boot 2.1 <https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8> [3] and Spring Data (Geode) Lovelace <https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12> [4] (or SDG 2.1 <https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10> [5]); This is not arbitrary because all the stars (bits, transitive dependency versions) must "align" as defined by what Spring Boot 2.1 declares, and Spring Boot 2.1 is based on <https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169> [6] Spring Data Lovelace/2.1. 4. Spring Data Geode (SDG) Lovelace/2.1 is based on <https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25> [7] Apache Geode 1.6. 5. All SDG Lovelace/2.1.x versions will always be based on the latest Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of time. This ship has sailed.
~~~~ 6. SBDG 1.2, when it reaches development (soon),will be based on Spring Boot 2.2 <https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8> [8], Spring Data (Geode) Moore <https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L12> [9] (or SDG 2.2 <https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L10> [10]); This is also not arbitrary because Spring Boot 2.2 declares a dependency on <https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L185> [11] Spring Data Moore. Again, the stars must align. 7. Spring Data Geode (SDG) Moore/2.2 is based on <https://github.com/spring-projects/spring-data-geode/blob/2.2.0.RC2/pom.xml#L25> [12] Apache Geode 1.9.0. 8. As you can see, SDG Moore/2.2 is already in release candidates (i.e. RC2 or the 2nd release candidate), which means SDG cannot be rebased on 1.10 at this point. The transitive dependency major.minor versions are now fixed for SD(G) Moore/2.2. 9. SDG Moore/2.2 can pick up any version of Apache Geode 1.9.x (e.g. 1.9.1 up to 1.9.N where N is 0... infinity). Finally, SDG's next opportunity to pick up Apache Geode 1.10 or 1.11 or 1.whatever is in the next SD Release Trains, Neuman, or 2.3. SDG can continue to pick up new versions of Apache Geode 1.10, 1.11, 1.12, etc until SDG Neuman/2.3 reaches it's first release candidate (RC) release, at which point the major.minor becomes fixed in that particular SD Release Train, until the next SD Release Train (Neuman.next). Make sense? So, it is the SDG version (along with Spring Boot core) that SBDG depends on that determines the version of Apache Geode that SBDG pulls in. Hope this helps! Regards, John [1] https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17 [2] https://github.com/spring-projects/spring-boot-data-geode/releases [3] https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8 [4] https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12 [5] https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10 [6] https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169 [7] https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25 [8] https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8 [9] https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L12 [10] https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L10 [11] https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L185 [12] https://github.com/spring-projects/spring-data-geode/blob/2.2.0.RC2/pom.xml#L25 On Tue, Aug 13, 2019 at 12:40 PM Aaron Lindsey <alind...@pivotal.io> wrote: > Thanks, Udo. > > +1 for doing a 1.9.1 patch release, assuming there is enough time for SBDG > to include it in their 1.2.x line. > > - Aaron > > > On Aug 13, 2019, at 12:38 PM, Udo Kohlmeyer <u...@apache.com> wrote: > > > > No, 1.9.1 IS something we require. SBDG 1.2 CAN use 1.9.1, we'd have to > wait for SBDG 1.3 to use 1.10 or 1.11 > > > > SBDG 1.3 is still a few months off, so maybe getting critical fixes in > patch versions is required. > > > > On 8/13/19 11:26 AM, Kirk Lund wrote: > >> Udo, Thanks for the info! Sounds like we shouldn't bother with Geode > 1.9.1 > >> then. If I'm misinterpreting what you wrote, let me know. > >> > >> On Tue, Aug 13, 2019 at 10:36 AM Udo Kohlmeyer <u...@apache.com> wrote: > >> > >>> The latest version of SBDG 1.2 is already in RC stage. Which means the > >>> dependent Geode version cannot be changed any more. Currently SBDG 1.2 > >>> is based on Geode 1.9. This will not change. Patch versions to 1.9 are > >>> supported, but not changes to 1.10 or later. > >>> > >>> THUS, > >>> > >>> Once SBDG 1.3 (Neuman) is released, it will be based on the latest GA > of > >>> Geode, which at this point would be 1.10 or possibly 1.11 depending on > >>> release cycles. > >>> > >>> In addition... > >>> > >>> @Aaron, Whilst it would also be possible to override the underlying > >>> Geode version that SBDG uses, to a later version, I would just like to > >>> point out that all testing of SBDG will be against a named supported > >>> version of Geode / GemFire. Which means, if failures arise using SBDG / > >>> SDG with a non-supported version of Geode / GemFire would effectively > be > >>> unsupported. (due diligence to confirm origin of failure will of course > >>> be applied) > >>> > >>> Hope this helps... > >>> > >>> --Udo > >>> > >>> On 8/13/19 10:03 AM, Aaron Lindsey wrote: > >>>> Assuming Geode 1.10 is released with the three logging fixes in Kirk’s > >>> message, can the next GA release of Spring Boot Data Geode consume 1.10 > >>> instead of 1.9? Also, when would SBDG need this patch release by > (whether > >>> we do a 1.9.1 release or 1.10 release)? > >>>> - Aaron > >>>> > >>>>> On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt < > bschucha...@pivotal.io> > >>> wrote: > >>>>> If we release a 1.9.1 I'd like to include the SSL/NIO fix. Cluster > SSL > >>> communications with conserve-sockets=false is currently broken in 1.9. > >>>>> On 8/13/19 9:25 AM, Kirk Lund wrote: > >>>>>> I'd like to discuss if and how we can release Geode 1.9.1 with > logging > >>>>>> improvements. This is primarily to provide a patch release for > Spring > >>> Data > >>>>>> Geode and Spring Boot to ensure a smoother User experience > out-of-the > >>> box. > >>>>>> They have very near-future releases that need this as soon as > possible. > >>>>>> > >>>>>> The specific tickets and commits that would be back-ported are: > >>>>>> > >>>>>> *1. GEODE-7058 Log4j-core dependency should be optional in > geode-core* > >>>>>> > >>>>>> commit 413800bc16d05df689a2af5c30797f180aad6088 > >>>>>> Author: Kirk Lund <kl...@apache.org> > >>>>>> Date: Wed Aug 7 14:33:21 2019 -0700 > >>>>>> > >>>>>> GEODE-7058: Mark log4j-core optional in geode-core > >>>>>> > >>>>>> Note: this change requires all commits from GEODE-2644 and > >>> GEODE-6122. > >>>>>> *2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers* > >>>>>> > >>>>>> commit e5c9c420f462149fd062847904e3435fbe99afb4 > >>>>>> Author: Kirk Lund <kl...@apache.org> > >>>>>> Date: Thu Aug 8 18:17:32 2019 -0700 > >>>>>> > >>>>>> GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider > >>> (#3892) > >>>>>> This change prevents Geode from using Log4jAgent if Log4j Core > is > >>>>>> present but not using Log4jProvider. > >>>>>> > >>>>>> For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in > >>> the > >>>>>> classpath. > >>>>>> > >>>>>> By disabling Log4jAgent when other Log4j Providers are in use, > >>> this > >>>>>> prevents problems such as ClassCastExceptions when attemping to > >>> cast > >>>>>> loggers from org.apache.logging.slf4j.SLF4JLogger to > >>>>>> org.apache.logging.log4j.core.Logger to get the LoggerConfig or > >>>>>> LoggerContext. > >>>>>> > >>>>>> Co-Authored-By: Aaron Lindsey <alind...@pivotal.io> > >>>>>> > >>>>>> *3. GEODE-6959 NPE if AlertAppender is not defined* > >>>>>> > >>>>>> commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89 > >>>>>> Author: Kirk Lund <kl...@apache.org> > >>>>>> Date: Thu Aug 8 14:59:44 2019 -0700 > >>>>>> > >>>>>> GEODE-6959: Prevent NPE in GMSMembershipManager for null > >>> AlertAppender > >>>>>> (#3899) > >>>>>> > >>>>>> If a custom log4j2.xml is used without specifying the Geode > >>>>>> AlertAppender, > >>>>>> GMSMembershipManager may throw a NullPointerException when > >>> invoking > >>>>>> AlertAppender.getInstance().stopSession() during a > >>> forceDisconnect. This > >>>>>> change prevents the NullPointerException allowing > forceDisconnect > >>> to > >>>>>> finish. > >>>>>> > >>>>>> Users using Spring Boot with Logback are more likely to hit > this > >>> bug. > >>>>>> Co-authored-by: Mark Hanson mhan...@pivotal.io > >>>>>> > > -- -John john.blum10101 (skype)
