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