How to automatically keep in sync with spring boot version

[StefanLobbenmeierObjego]

Is your feature request related to a problem? Please describe.
It is a tedious to make sure that the selected cloud stream version and the spring boot version are kept in sync. This also shows in the amount of questions about compatability that are asked in this project.

Describe the solution you'd like
A) manage spring cloud stream version as part of the spring boot dependencies bom:
https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-dependencies/build.gradle

B) create a new spring overarching dependencies bom that includes the spring boot dependencies bom as well as spring cloud dependencies

C) align version numbers so they can be shares as a single variable

D) add a spring cloud bom that is more strict about dependency resolution so it fails on its own when conflicting versions are used

Describe alternatives you've considered
Turning off renovate upgrades for spring cloudstream and manually applying them to spring boot upgrade PRs

Additional context

[spencergibb]

Are you using the spring-cloud-dependencies bom?

'A' cannot happen since spring cloud depends on spring boot and we will not introduce circular dependencies

'B', while possible is doubtful. Spring Cloud separates itself from boot so users can upgrade patch versions independently.

'C' again, while possible is again doubtful. This is not required anywhere in the spring portfolio. This would require spring boot skipping a major version.

'D' I'm unsure what you mean by a stricter bom. Typically spring cloud supports two minor versions, not just patch versions.

We have runtime checking of boot version compatibility that should fail builds with, is that not working for you?

[spencergibb]

I will talk to colleagues about it also

[StefanLobbenmeierObjego]

We have runtime checking of boot version compatibility that should fail builds with, is that not working for you?

That would work - since we can just check if contextLoads and then we should be safe at PR time. But it does not seem to be working, we updated to 2024 release train while we are still on 3.3.6 and only noticed issues after the application was already running for some time.

Regarding D I was wondering if something like this could fail at dependency resolution:
https://github.com/spring-projects/spring-boot/blob/8308e9e976e554cc589d16547caf5ac395b9af0d/spring-boot-project/spring-boot-dependencies/build.gradle#L306

I will set up an example repo here to find the runtime check, maybe its only the way our build is set up that the check is not working or something.

[StefanLobbenmeierObjego]

Prepared an example repo, I would expect either dependency resolution to fail or at least contextLoads to not succeed because of the runtime check:
https://github.com/StefanLobbenmeierObjego/spring-boot-and-spring-cloud-dependecy-management

Maybe the runtime check is just in some libraries of spring cloud?

[spencergibb]

So your example doesn't use any spring-cloud starters.

implementation("org.springframework.cloud:spring-cloud-starter")

If it did, you would get the following error

***************************
APPLICATION FAILED TO START
***************************

Description:

Your project setup is incompatible with our requirements due to following reasons:

- Spring Boot [3.3.6] is not compatible with this Spring Cloud release train


Action:

Consider applying the following actions:

- Change Spring Boot version to one of the following versions [3.4.x] .
You can find the latest Spring Boot versions here [https://spring.io/projects/spring-boot#learn]. 
If you want to learn more about the Spring Cloud Release train compatibility, you can visit this page [https://spring.io/projects/spring-cloud#overview] and check the [Release Trains] section.
If you want to disable this check, just set the property [spring.cloud.compatibility-verifier.enabled=false]

There are two specific issues here, one is that there isn't a starter for spring-cloud-stream-binder-kafka-streams and the other is that the existing stream starters don't include spring-cloud-starter.

@olegz @sobychacko thoughts on this?

[StefanLobbenmeierObjego]

I can confirm, adding that additional dependency to my project gives me the error:

Caused by: org.springframework.cloud.configuration.CompatibilityNotMetException: Spring Cloud/ Spring Boot version compatibility checks have failed: [[VerificationResult@690c0c33 description = 'Spring Boot [3.3.6] is not compatible with this Spring Cloud release train', action = 'Change Spring Boot version to one of the following versions [3.4.x] .
You can find the latest Spring Boot versions here [https://spring.io/projects/spring-boot#learn]. 
If you want to learn more about the Spring Cloud Release train compatibility, you can visit this page [https://spring.io/projects/spring-cloud#overview] and check the [Release Trains] section.
If you want to disable this check, just set the property [spring.cloud.compatibility-verifier.enabled=false]']]

So adding the additional dependency should be a good workaround until it is included by default, right?

[spencergibb]

So adding the additional dependency should be a good workaround until it is included by default, right?

Yes

[sebphil]

Hi! I'm also struggling to keep spring boot and spring cloud versions in sync. Today renovate told me that spring boot 3.5.0 was available, but there was no error at build time so this update was deployed to my test server, and only then did the spring cloud compatibility check throw an error, so I had to rollback the spring boot update.

I would really love to be able to have this compatibility checked at build time rather than at runtime. The idea to use an empty integration test to force an application context start during the build phase looks nice, but it doesn't work for me out of the box because I only include the spring cloud starter dependency when I'm building my container image and not when I execute unit tests.

As a workaround, I ended up including the spring-cloud-commons dependency with a "test" scope, and I added this minimal integration test that only executes the spring cloud compatibility check:

import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.cloud.configuration.CompatibilityVerifierAutoConfiguration;

@SpringBootTest(classes = CompatibilityVerifierAutoConfiguration.class)
class SpringCloudCompatibilityVerifierTest {

    @Test
    void contextLoads() {
    }
}

[spencergibb]

Without creating a maven and gradle plug-in, there really can't be a build time check

[StefanLobbenmeierObjego]

Circling back on this:

'D' I'm unsure what you mean by a stricter bom. Typically spring cloud supports two minor versions, not just patch versions.

If the spring cloud bom were to use strict versions this should be possible, no?:
https://docs.gradle.org/current/userguide/dependency_versions.html#sec:strict-version

strictly or !!
This is the strongest version declaration. Any version not matching this notation will be excluded. If used on a declared dependency, strictly can downgrade a version. For transitive dependencies, if no acceptable version is found, dependency resolution will fail.
Dynamic versions are supported.
When defined, it overrides any previous require declaration and clears any previous reject already declared on that dependency.

So something like this should be possible:

dependencies {
    implementation("org.springframework.boot:spring-boot-starter") {
        version {
            strictly("[3.5.0, 3.6.0[")
        }
    }
}

e.g. if I put two of those conflicting dependencies directly into my build script I get an error at build time:

implementation("org.springframework.boot:spring-boot-starter") {
        version {
            strictly("[3.4.0, 3.5.0[")
        }
    }
    implementation("org.springframework.boot:spring-boot-starter") {
        version {
            strictly("[3.5.0, 3.6.0[")
        }
    }

Cannot find a version of 'org.springframework.boot:spring-boot-starter' that satisfies the version constraints

putting only one of them seems to actually override the spring boot bom even if it is a different version, so I think also the spring boot bom would need to have a strict version in their dependencies:

I use them like this

    implementation ( platform(SpringBootPlugin.BOM_COORDINATES) )

but source is found here https://github.com/spring-projects/spring-boot/blob/8308e9e976e554cc589d16547caf5ac395b9af0d/spring-boot-project/spring-boot-dependencies/build.gradle#L1949 and there does not seem to be any strict version requirements

[spencergibb]

We don't use gradle