Release trains
As we can see in the preceding diagram, there are many projects inside Spring Cloud and there are many relationships between them. By definition, these are all independent projects with different release cascades and version numbers. In a situation like this, dependency management in our application might be problematic and that will require knowledge about relationships between versions of all projects. To help make it easier, Spring Cloud introduced the starter mechanism, which we have already discussed, and release trains. The release trains are identified by names, not versions, to avoid confusion with the subprojects. What is interesting is that they are named after London tube stations and they are alphabetically ordered. The first release was Angel, the second was Brixton, and so on. The whole mechanism of dependency management is based on BOM (bill of materials), which is a standard Maven concept for managing artifacts versioned independently. Here's an actual table with Spring Cloud project versions assigned to release trains. Names with the suffix M[X], where [X] is the version number, means milestone, SR[X] means service release, which refers to changes that fix critical bugs. As you can see in the following table, Spring Cloud Stream has it own release trains, which groups its subprojects using the same rules as Spring Cloud project:
Component | Camden.SR7 | Dalston.SR4 | Edgware.M1 | Finchley.M2 | Finchley.BUILD-SNAPSHOT |
spring-cloud-aws | 1.1.4.RELEASE | 1.2.1.RELEASE | 1.2.1.RELEASE | 2.0.0.M1 | 2.0.0.BUILD-SNAPSHOT |
spring-cloud-bus | 1.2.2.RELEASE | 1.3.1.RELEASE | 1.3.1.RELEASE | 2.0.0.M1 | 2.0.0.BUILD-SNAPSHOT |
spring-cloud-cli | 1.2.4.RELEASE | 1.3.4.RELEASE | 1.4.0.M1 | 2.0.0.M1 | 2.0.0.BUILD-SNAPSHOT |
spring-cloud-commons | 1.1.9.RELEASE | 1.2.4.RELEASE | 1.3.0.M1 | 2.0.0.M2 | 2.0.0.BUILD-SNAPSHOT |
spring-cloud-contract | 1.0.5.RELEASE | 1.1.4.RELEASE | 1.2.0.M1 | 2.0.0.M2 | 2.0.0.BUILD-SNAPSHOT |
spring-cloud-config | 1.2.3.RELEASE | 1.3.3.RELEASE | 1.4.0.M1 | 2.0.0.M2 | 2.0.0.BUILD-SNAPSHOT |
spring-cloud-netflix | 1.2.7.RELEASE | 1.3.5.RELEASE | 1.4.0.M1 | 2.0.0.M2 | 2.0.0.BUILD-SNAPSHOT |
spring-cloud-security | 1.1.4.RELEASE | 1.2.1.RELEASE | 1.2.1.RELEASE | 2.0.0.M1 | 2.0.0.BUILD-SNAPSHOT |
spring-cloud-cloudfoundry | 1.0.1.RELEASE | 1.1.0.RELEASE | 1.1.0.RELEASE | 2.0.0.M1 | 2.0.0.BUILD-SNAPSHOT |
spring-cloud-consul | 1.1.4.RELEASE | 1.2.1.RELEASE | 1.2.1.RELEASE | 2.0.0.M1 | 2.0.0.BUILD-SNAPSHOT |
spring-cloud-sleuth | 1.1.3.RELEASE | 1.2.5.RELEASE | 1.3.0.M1 | 2.0.0.M2 | 2.0.0.BUILD-SNAPSHOT |
spring-cloud-stream | Brooklyn.SR3 | Chelsea.SR2 | Ditmars.M2 | Elmhurst.M1 | Elmhurst.BUILD-SNAPSHOT |
spring-cloud-zookeeper | 1.0.4.RELEASE | 1.1.2.RELEASE | 1.2.0.M1 | 2.0.0.M1 | 2.0.0.BUILD-SNAPSHOT |
spring-boot | 1.4.5.RELEASE | 1.5.4.RELEASE | 1.5.6.RELEASE | 2.0.0.M3 | 2.0.0.M3 |
spring-cloud-task | 1.0.3.RELEASE | 1.1.2.RELEASE | 1.2.0.RELEASE | 2.0.0.M1 | 2.0.0.RELEASE |
Now, all we need to do is provide the right release train name in the dependency management section in the Maven pom.xml and then include projects using starters:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Finchley.M2</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
...
</dependencies>
Here's the same sample for Gradle:
dependencyManagement {
imports {
mavenBom ':spring-cloud-dependencies:Finchley.M2'
}
}
dependencies {
compile ':spring-cloud-starter-config'
...
}