As you can see here: https://spring.io/projects/generations#mappings
Certain versions of Spring Cloud are compatible with certain versions of Spring Boot. We need to add a validation for this into the version validation feature set that we already have.
The details here are:
- we need to check whether the used release train version of Spring Cloud supports the version of Spring Boot that is used in the project. If not, create a corresponding diagnostics.
- the diagnostics should contain information about the version of Spring Cloud that should be used - but there might be no compatible version of Spring Cloud (yet at that moment in time, e.g. after Boot was released, before Cloud is released)
- we will not include logic to inform the user about newer versions of Spring Cloud being available, since there is always one specific Spring Cloud version that is compatible (and therefore should be used) for every version of Spring Boot. So users will change the version of Spring Boot first, then select the right version of Spring Cloud (maybe we can automate that, but that is a different story).
Logic to identify the used version of Spring Cloud:
- The assumption is that users will always use the Spring Cloud BOM for this and specify the train version here - instead of setting individual versions for individual artifacts.
- we look at the classpath for the cloud commons JAR file and identify the train version from there (attention: the train version is not the same as the cloud commons JAR file, we need to identify the corresponding release train version first once we have the version of the JAR file.
- there are a few corner cases where people use components from spring cloud without having cloud commons automatically on the classpath (older versions of spring-cloud-function and spring-cloud-streaming). For those cases (there is no cloud commons JAR on the classpath), we need to look for those two specific JARs and identify the release train version from there.
The issue of identifying the release train version from an individual artifact version can also be implemented using the linkedGenerations information (in that case for the individual artifact).
One pre-requisite is to get the information about linked generations included in the API here (e.g.):
https://api.spring.io/projects/spring-cloud/generations
As you can see here: https://spring.io/projects/generations#mappings
Certain versions of Spring Cloud are compatible with certain versions of Spring Boot. We need to add a validation for this into the version validation feature set that we already have.
The details here are:
Logic to identify the used version of Spring Cloud:
The issue of identifying the release train version from an individual artifact version can also be implemented using the
linkedGenerationsinformation (in that case for the individual artifact).One pre-requisite is to get the information about linked generations included in the API here (e.g.):
https://api.spring.io/projects/spring-cloud/generations