[Macha]

"Oh look, I need to upgrade mockito and Spring. Oh, now I upgraded Spring I need to update the spring JPA plugin. Oh now I upgraded that I need to upgrade Hibernate. Oh now I need to upgrade the library built on it that that team over there maintains. Oh, they're not interested." etc. etc.

[ivan_gammel]

When using Spring Boot you usually update just one version and everything else is updated via BOM. There should be a really good reason to have fine-grained control over every single dependency.

[Macha]

Not every app using Spring is using Spring boot

[ivan_gammel]

You don’t have to use its functionality to use its BOM.

[Macha]

So honestly I didn't realise that it's POM extended to ecosystem libraries beyond Spring's own. However, it still doesn't solve the problem that e.g. the hibernate version compatible with Spring Framework n+1 is not compatible with the hibernate version compatible with Spring Framework n and now you're doing an "all or nothing" upgrade, which for a large app can be time consuming.

[ivan_gammel]

The point of using BOM is to avoid specifying dependency versions of individual components, so this problem is in reality non-existent. The only case when you would actually need to have different version of Hibernate than in your BOM is some critical bug fix, which is very likely a patch version and is very unlikely to break compatibility with the rest of your setup.

[dingi]

True, Spring upgrades can be a pain in the ass. There is a trick to make it less painful though. Use maven BOM for version management. As with any framework upgrade, it doesn't make the process entirely painless. But very much less painful.

[dionian]

Having a lot of experience with that stack... it is why i migrated to scala long ago

[paulddraper]

Tho Scala makes the upgrade problem even worse:)