Upgrade to Spring for Apache Geode SNAPSHOTS

[jxblum]

Currently, due to Issue #510, the Spring for Apache Geode bits are out of sync for SNAPSHOT versions of Spring Boot.

For instance, Spring Boot 2.4.0-SNAPSHOT should produce Spring for Apache Geode 1.4.0-SNAPSHOT, but is incorrectly set to 1.4.0-M1, which is already picked up by selecting Spring Boot 2.4.0-M1.

Additionally, Spring Boot 2.3.3.BUILD-SNAPSHOT should produce Spring for Apache Geode 1.3.3.BUILD-SNAPSHOT, but is incorrectly set to 1.3.2.RELEASE, which is already picked up by selecting Spring Boot 2.3.2.RELEASE.

Finally, Spring Boot 2.2.10.BUILD-SNAPSHOT should produce Spring for Apache Geode 1.2.10.BUILD-SNAPSHOT, but is incorrectly set to 1.2.9.RELEASE, which is already picked up by selecting Spring Boot 2.2.9.RELEASE.

[snicoll]

Currently, due to Issue #510, the Spring for Apache Geode bits are out of sync for SNAPSHOT versions of Spring Boot.

I don't understand how that issue relates to the fact start.spring.io doesn't serve snapshots for the Geode integration. Can you please clarify?

[jxblum]

@mbhave found a bug where the updates/upgrades were not being properly picked up and applied in a timely manner. The changes for all the latest Issues (#495, #496, #497 and #508) I submitted (some, over 2 weeks ago now) had not updated Spring Initializer at start.spring.io with the latest "Spring for Apache Geode" bits.

Are you aware that, until recently after @mbhave corrected the problem, if a user selected Spring Boot 2.3.2.RELEASE users would get SBDG 1.3.0.RELEASE and should have gotten at least 1.3.1.RELEASE since #495 (16 days ago) and now should be getting 1.3.2.RELEASE as of #508 (4 days ago).

These untimely, severely delayed updates affect both users and customers alike.

After @mbhave corrected the RELEASE versions to reflect all my recently submitted Issues (not sure what she did), which are now up-to-date, the SNAPSHOT versions are still incorrect, hence this ticket.

The question I have is, how can we (automatically?) detect this sooner (with proper checks) and avoid problems like this in the future as it has a negative impact to our end-users and customers?

[snicoll]

I am aware of the problem and that the problem has a workaround for now. The issue you've referenced is to figure out how we can make sure we know about that kind of problem upfront.

We've already discussed about integrating snapshots of Geode and this was declined in #381. Is there anything new since we've discussed this request? (in particular activity in maintenance branches that would justify us switching to snapshots, and aligned dependency management with spring-boot-dependencies ?)

[jxblum]

None of the old arguments from #381 apply.

1. SBDG dependencies are aligned with Spring Boot, and have strictly been for awhile.

2. I most certainly have and do back port important changes.

In fact, since SBDG 1.2 (aligning with Spring Boot 2.2) I have even kept pace with Spring Boot patch releases from 2.2 onwards (i.e. 2.2, 2.3, and now 2.4; SBDG's 1.2, 1.3 and 1.4), 1-for-1, no exceptions.

3. SBDG Milestones (M#), Release Candidates (RC#), GA Releases (RELEASE), and even [BUILD-]SNAPSHOTs always align with Spring Boot .minor.patch dependencies and versions.

I am very careful and meticulous about doing this now. I am 1 major version behind, but I cannot help that (I am also not going to skip a major version just to align solely on version numbers). However, everything else (.minor.patcth version numbers, dependencies, etc) all align as can be seen in the version compatibility matrix.

4. I thought I remember seeing BUILD-SNAPSHOTS of the "Spring for Apache Geode" bits on Spring Initializer at start.spring.io.

E.g. I thought SBDG 1.2.9.BUILD-SNAPSHOT was provided when a user selected Spring Boot 1.2.9.BUILD-SNAPSHOT (at the time). However...

5. It seems I may have been mistaken about that, and if so, I stand corrected. My apologies.

6. Feel free to close this ticket without further action then.

[snicoll]

Thanks for the feedback.

None of the old arguments from #381 apply.

I am not so sure about that. Looking at the repository and Andy's comment on #381, it looks like the project still overrides those dependencies. The argument was that they shouldn't be defined at all so that whatever Spring Boot uses is what you use. This may not be what you want, in particular when you need to work with a SNAPSHOT of dependency (such as Spring Data) and the main reason we're not keen to enable snapshots for the project.

[jxblum]

_The argument was that they shouldn't be defined at all _

Well, with all due respect, that decision is not up to anyone else but myself 1) being the lead and (only) maintainer for all things on this project and 2) when I have customers in addition to users to be concerned with.

whatever Spring Boot uses is what you use

For all Milestones, Release Candidates, RELEASE(s) and even [BUILD-]SNAPSHOT bits pushed to repo.spring.io or MC, dependencies are aligned with Spring Boot. I make a best effort never to deviate when it comes to bits users and customers alike consume so that they have a "consistent" experience. So...

It's not what I want. It's what I need to do to support GemFire/Geode (both past and future versions) which has a very different life/support cycles then most of our projects, which are not tied to commercial/legal obligations (e.g. SDG/SBDG version is technically EOL but the GemFire/Geode version on which SDG/SBDG is based is still "officially" supported, by contract no-less, or vice versa (e.g. right now, SD Lovelace; i.e. the GemFire/Geode version is no longer in support, but Lovelace is #sigh)). This makes it very challenging for me.

Anyway...

I am sure any argument I make will be a moot point and I don't feel like justifying myself yet again.

I'll figure something else out.

[snicoll]

Well, with all due respect, that decision is not up to anyone else but myself

Absolutely. And just like it is definitely your call to decide how the build of this project is structured, it is also our responsability to explain and enforce the conditions in which a SNAPSHOT can be provided on the site.

It's not what I want. It's what I need to do to support GemFire/Geode (both past and future versions) which has a very different life/support cycles then most of our projects

We've had numerous conversations on this topic and I am aware of those constraints. Unfortunately, adding snapshots for this project in the current form can lead to broken projects and the reason this request was declined earlier this year (#381) and here.

Let me take an example to describe a potential problem. Let's assume you need to override some dependencies to benefit from a code change in Spring Data that adds a new method you need to call. You make that change and publish a new SNAPSHOT.
On the Spring Boot side of things, we're not using a snapshot of Spring Data (as we often do). Generating a project with your updated snapshot and the current Spring Boot dependnecy management will lead to an error as the version of those two dependencies are driven by Spring Boot (via its import of the Spring Data releasetrain bom), not your override.

Given that the state of the build is exacty the same as when we discussed this topic in February, I don't see anything new to be discussed. If I've overlooked someting, I am happy to discuss some more.