Does anyone know what the next step is? Do we need a release manager to proceed?
On Tue, Aug 13, 2019 at 1:57 PM John Blum <jb...@pivotal.io> wrote: > Sorry, corrections below... > > On Tue, Aug 13, 2019 at 1:54 PM John Blum <jb...@pivotal.io> wrote: > > > Stated slightly a different way... > > > > If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly, then > > it would *defy* the dependency on Apache Geode pulled in by SDG Moore/2.2 > > (which is and can only be Geode 1.9 *at this point*) for which SBDG is > > also based, along with Spring Boot 2.2, which pulls in SD Moore/2.2 and > > therefore Geode 1.9, *indirectly (i.e. transitively)*, as well. As such, > > the stars would not align and it would cause issues (or unexpected > > surprises, possibly conflicts) for users of Spring Boot when also using > > SBDG. *With**out* SBDG, users of Spring Boot would get Geode 1.9 due to > > the SD Moore/2.2 dependency, but with SBDG on the classpath, it would > > suddenly (possibly) change the Geode version to 1.10. That is > definitively > > bad. > > > > Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9. > > > > SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not > > available) which will pull in the latest version of Geode at that time > > (e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3 reaches RC > > status. > > > > Cheers, > > John > > > > > > > > > > On Tue, Aug 13, 2019 at 1:45 PM John Blum <jb...@pivotal.io> wrote: > > > >> 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) > >> > > > > > > -- > > -John > > john.blum10101 (skype) > > > > > -- > -John > john.blum10101 (skype) >
