Overriding spring boot BOM curated dependency with higher version

Question

Spring boot document suggest mostly you don't need to override the BOM dependency in practice.

As there are provisions to override the dependency. Scenario :: Declared in parent pom :

<dependencyManagement>
    <dependencies>
     <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>2.1.4</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

Declared in child pom

 <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-mongodb</artifactId>
    </dependency>

Is it right/best practice to override spring-boot-starter-data-mongodb with higher version lets say 2.2.1 for spring boot 2.1.4

My take is override with downgraded version seems okay in theory , but to upgrade to higher version may invite issues.

Also despite overriding the declaration in parent pom, dependency of overridden dependency still as per the BOM decalaration.

<dependencyManagement>
    <dependencies>
  <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-mongodb</artifactId>
      <version>2.2.1.RELEASE</version>
    </dependency>
     <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>2.1.4</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

Answer 1

I think there is a risk in doing this but sometimes it has to be done. You or the team would have to weigh the pros/cons. Here are some situations that may lead to advancing a dependency's version ahead of the BOM.

• Security. Sometimes a dependency has a a CVE vulnerability. Security scans may catch this and prevent your application from being deployed.
• New required feature. The newer version of the dependency might have a feature your software requires.
• Bug fix. The newer version of the dependency might have a bug fix.

Things to take into account before doing this:

• Consider upgrading the BOM first. It could be the case that the BOM has a newer version with the desired dependency version.
• If you go the route of upgrading the BOM, this might actually have a bigger impact on your application as it will lead to multiple dependencies being upgraded.
• Testing, testing, and more testing. Whether you go with dependency upgrade or BOM upgrade, testing is your best friend. With good testing coverage, you can move forward confidently. Having great testing has an amazing ROI when you consider how quickly and confidently you can upgrade dependencies.
• Upgrading a bug version, versus feature version, is less risky. Basically, if the dependency's version is only upgrading the third number in the version (the 'z' in version x.y.z) it's less risky than if it was the second.