Upgrade to Spring for Apache Geode 1.2.5.BUILD-SNAPSHOT

[jxblum]

SBDG 1.2.5.BIULD-SNAPSHOT is based on Spring Boot 2.2.5.BUILD-SNAPSHOT.

Thank you

[snicoll]

Thanks for the request but we usually switch to a snapshot of Spring Data (on which this project builds upon) a bit before releasing a maintenance release. Getting snapshots for this project feels inconsistent to me.

[jxblum]

Hi @snicoll - Thank you for your consideration. I am not quite sure I am following your reasoning, though.

1) First, SBDG builds on both Spring Boot (first) and Spring Data (second).

2) Second, are you saying because SBDG 1.2.x (e.g. 1.2.5.BUILD-SNAPSHOT) builds with Spring Data (and Spring Session, for that matter) build snapshots (rather than the latest release versions, e.g. SD Moore-SR4), ahead of Spring Boot (e.g. 2.2.5.BUILD-SNAPSHOT), which sticks to dependency release versions until a new Spring Boot maintenance version (i.e. 2.2.5.RELEASE) is about to be released, then it does make sense to add an entry to Spring Initializer for SBDG 1.2.x build snapshots?

If so...

2.1) Would me switching SBDG to keep with SD and SS release versions in maintenance release build snapshots (e.g. SBDG 1.2.5.BUILD-SNAPSHOT) change anything (?), and ...

2.2) I am curious if I am doing a bad practice here by having SBDG maintenance version build snapshots build with (controlled) transitive dependency version build snapshots, like this?

For instance, why does Spring Boot not follow this convention?

I mean wouldn't picking up possible breaking changes well ahead of your next maintenance release, e.g. 2.2.5.RELEASE, by building with SD Moore-BUILD-SNAPSHOT, if something significant in SD 2.2.5.RELEASE were about to change, wouldn't that give you much better and quicker visibility by building with SD Moore-BUILD-SNAPSHOT rather than Moore-SR4?

Of course, I get that this would potentially have consequences for users starting and start.spring.io using Spring Boot build snapshots.

FTR, when I say "controlled" transitive dependencies in SBDG, I simply mean dependencies we control, namely all Spring bits (Spring Boot, Spring Data, Spring Session, etc, anything SBDG builds on in the Spring portfolio). I do not use build snapshots of 3rd party dependencies. For the most, part, I even let Spring Boot control my direct and transitive dependencies save for a very few (e.g. Mockito, which is only used in SBDG's tests). Still, I only use "release" artifacts of 3rd party dependencies.

Anyway, let me know if it is possible to do this if I change my Spring bits to match Spring Boot's managed dependencies.

Thank you.

[wilkinsona]

Hi, John. We had a chat about this on our team call today. The TL;DR is that we're happy to include SBDG snapshots on start.spring.io as long as it's managed in a similar manner to Spring Cloud.

start.spring.io includes Spring Cloud snapshots but, as far as we know, those snapshots do not override the versions of any main (non-test) dependencies that Spring Boot manages. This gives some guarantees that if Spring Cloud's snapshot builds pass, things will also work for anyone generating a snapshot-based app on start.spring.io where Spring Boot's dependency management will control the versions.

2.1) Would me switching SBDG to keep with SD and SS release versions in maintenance release build snapshots (e.g. SBDG 1.2.5.BUILD-SNAPSHOT) change anything (?), and ...

If you follow the Spring Cloud model and used Spring Boot's dependency management for your main dependencies (test dependencies are not a concern) if would change the situation for the better, making it easier to include SBDG on start.spring.io.

if something significant in SD 2.2.5.RELEASE were about to change, wouldn't that give you much better and quicker visibility by building with SD Moore-BUILD-SNAPSHOT rather than Moore-SR4?

Yeah, it does give us better visibility, and this is why we upgrade to snapshots of other Spring projects a while (usually a week or so) before each Spring Boot maintenance release. There's not much science behind that period, other than the feeling that it strikes the right balance between getting visibility into any problems and keeping Boot's build as stable as possible.

The other thing that Spring Cloud does is make quite a few changes in each release. There's a cost to managing a snapshot dependency version on start.spring.io so it's important that there's a benefit that outweighs that cost. Making it easy for users to try out frequently changing snapshot builds makes provides that benefit.

We noticed that the SBDG 1.2.5 snapshots have been pretty quiet thus far. Perhaps that's unusual and there's normal more activity in maintenance releases? We just want to make sure that the cost was considered and that the benefit to users would be sufficient to justify that cost.

[jxblum]

Hi Andy- Just wanted to acknowledge I have read your response. Thank you for your comments and consideration.

I only quickly read through this since I started reading this over the weekend. Everything you are saying makes sense.

In between my last comment and your followup remarks, I had made changes to the SBDG 1.2.x branch to align with Spring Boot 2.2.x build snapshot dependencies.

NOTE: FYI, SBDG 1.2.x is currently building 1.2.5.BUILD-SNAPSHOTs based onSpring Boot 2.2.5.BUILD-SNAPSHOTs.

However, I see now that Spring Boot's dependencies on the (core) Spring Framework has switched to 5.2.4.BUILD-SNAPSHOT, Spring Data to Moore-BUILD-SNAPSHOT and Spring Session to Corn-SR1, most likely in anticipation of the upcoming 2.2.5.RELEASE (tentatively) scheduled for this Thursday, 2/27, which as you stated, is ~ a week or so prior to a release.

Therefore, I have once again realigned SBDG 1.2.x with Spring Boot 2.2.x.

In a nutshell, I primarily use Spring Boot Dependency Management to manage SBDG's dependencies most of the time, as defined by this and this.

I do give myself an option to override these dependencies as necessary for testing purposes, particularly if a user or customer reports an issue with versions. This is the sole purpose of the explicit Spring version properties declarations in SBDG's gradle.properties, otherwises these Spring version properties are not used.

Finally, I do further afford myself an option to specifically control and override the Spring Data for Apache Geode/Pivotal GemFire (SDG), Spring Session for Apache Geode/Pivotal GemFire (SSDG), and Spring Test for Apache Geode/Pivotal GemFire (STDG) versions as necessary, again usually for development and testing purposes, as seen here.

SBDG builds on SDG, SSDG and STDG (things I control) in addition to Spring Boot, and therefore I might need further refinement of the GemFire/Geode dependencies during development while keeping all other Spring bits neatly aligned, as defined by Spring Boot.

However, in summary, the stars should usually align pending circumstance. I also try very hard to keep the build(s) stable and monitor them continuously (daily).

I will review what the Spring Cloud team does. In the meantime let me know if you have further questions or concerns.

Thank you, John

[wilkinsona]

Thanks, @jxblum. One change that I think it would be nice to see is for none of Spring Boot's dependency management to be overridden by default. Specifically, this dependency management seems to introduce a risk that what is being tested against will not be aligned with what's in the "target" versions of Spring Boot and Spring Data. This, I think, is the major difference between your approach and that of Spring Cloud.