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.