I volunteer to pair with a more experienced release manager for 1.9.1. Anyone willing to mentor me on this?
On Sun, Aug 18, 2019 at 7:53 AM Anthony Baker <aba...@pivotal.io> wrote: > Yep. Get a release manager, identify and cherry pick all the changes, then > do the release. > > Anthony > > > On Aug 16, 2019, at 4:21 PM, Kirk Lund <kl...@apache.org> wrote: > > > > 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) > >> >
