Spring IO platform release management

Question

Since Spring IO platform was intruduced we manage our project dependencies using the Spring IO platform-bom. Thus we do not specify dedicated versions for single Spring components (or even the platform libraries) anymore (and we are cautious when it comes to overwrite them).

The disadvantage of this solution is, that we can not use new versions of single components as recommended like e.g. the (yesterday) announced new version 4.1.6 of the Spring Framework until it is integrated into a new version of the Spring IO platform.

It would be nice to know more about the release management of Spring IO platform. Is there a general plan when to release a new version? I thought that in fact a new version of Spring Framework would trigger a new version of the Spring IO platform but that does not seem to be the case (there was no new version with Spring Framework 4.1.5 and I suppose the next version will include Spring Framework 4.1.6).

Any insights into the release management of the Spring IO platform would be interesting and helpful for me.

Socinus

Have you tried overriding the property spring.framework.version? – Judiciary

@chrylis Overriding would probably work but would somehow harm the integrity of the well matched module versions in the platform-bom - so that is not what I would like to do. – Socinus

Not if you're only overriding within minor versions, which are bugfixes. – Judiciary

@chrylis That might be right and could be a workaround. But adjusting all (new) project versions is probably not that what you want to do when using the platform-bom. – Socinus

Answer 1

The general rule of thumb is that we release a new version of the Platform every 6-8 weeks. That's not set in stone as there will be occasions where more frequent releases are warranted; to address a security vulnerability, for example.

As you may already know, the Platform builds on top of Spring Boot. It extends Spring Boot's bom, adding dependency management for a number of other Spring projects and their dependencies. Generally speaking, when a new version of Spring Boot is released that will trigger the release of a new version of the Platform. Furthermore, a new version of Spring Framework will often trigger the release of a new version of Spring Boot.

As you've observed, Spring Framework 4.1.5 and Spring Boot 1.2.2 were an exception to this rule. While Spring Boot 1.2.2 was released shortly after Spring Framework 4.1.5, there's no version of the Platform that contains these two releases. The reason for this is that there were a couple of Spring Security-related bugs in Spring Boot 1.2.2 that we wanted to help users of the Platform to avoid. To achieve this, we decided to postpone the release of Platform 1.1.2 until Spring Boot 1.2.3 was available and the Spring Security issues had been addressed. There's a slight trade-off here between being on the leading edge and having some protection from bugs.

You should consider the Platform as a recommended set of versions to use, but it is definitely not the only set of versions that you can use. The use of version properties in the Platform's bom is deliberate and it makes it easy for users to override the versions to meet their needs. The leads of the various Spring projects take backwards compatibility very seriously and you should always be able to upgrade to a newer maintenance release of any project without any difficulties. In many cases you will also be able to upgrade to a new minor version but more caution would be warranted.

Hartsfield

Do you really mean 'minor' version in your last sentence? – Socinus

I do. In many cases going from 1.0.x to 1.1.x of a project will go without a hitch but there may be a little bit of work to do. We don't take a dogmatic approach to semantic versioning so it's wise to check a project's release notes when adopting a new minor (or major version). Picking up a new maintenance version (moving from 1.0.x to 1.0.y) should always go without a hitch. If it doesn't, you've almost certainly found a bug. – Hartsfield

Thank's for clarification - I mixed up major/minor/patch level and thought it could be also ok to switch to a new major version (as Spring Framwork as far as I noticed is also very backwards compatibel and it mostly was no problem to upgrade to a new major version). – Socinus