I will pair with you on a 1.9.1 release.
> On Aug 19, 2019, at 9:23 AM, Kirk Lund <kl...@apache.org> wrote:
>
> 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)
>>>>
>>
