Переопределение зависимой спецификации весенней загрузки с более высокой версией

Question

Загрузочный документ Spring предполагает, что в большинстве случаев вам не нужно переопределять зависимость спецификации на практике.

Поскольку существуют положения, позволяющие переопределить зависимость. Сценарий :: Объявлен в родительском 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>

Объявлен в дочернем pom

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

Правильно ли / наилучшая практика переопределять spring-boot-starter-data-mongodb с более высокой версией скажем, 2.2.1 для весенней загрузки 2.1.4

Теоретически, мой вариант переопределен с версией более ранней версии, но при обновлении до более высокой версии могут возникнуть проблемы.

Также несмотря на переопределение декларации в родительском помпе зависимость переопределенной зависимости по-прежнему соответствует декалерации спецификации.

<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

Я думаю, что в этом есть риск, но иногда это нужно делать. Вы или команда должны были бы взвесить все за / против. Вот некоторые ситуации, которые могут привести к продвижению версии зависимости перед спецификацией.

• Безопасность. Иногда зависимость имеет уязвимость CVE. Сканирование безопасности может это уловить и помешать развертыванию приложения.
• Новая необходимая функция. В более новой версии зависимости может быть функция, которая требуется вашему программному обеспечению.
• Исправление ошибки. В более новой версии зависимости может быть исправлена ​​ошибка.

Что необходимо учесть, прежде чем делать это:

• Сначала рассмотрите возможность обновления спецификации. Может случиться так, что спецификация будет иметь более новую версию с требуемой версией зависимости.
• Если вы go выберете путь обновления спецификации, это может оказать большее влияние на ваше приложение, поскольку это приведет к к множеству обновляемых зависимостей.
• Тестирование, тестирование и другое тестирование. Если у вас go с обновлением зависимостей или обновлением спецификации, тестирование - ваш лучший друг С хорошим тестированием вы можете уверенно двигаться вперед. Хорошее тестирование дает потрясающую рентабельность инвестиций, если учесть, насколько быстро и уверенно можно обновлять зависимости.
• Обновление версии с ошибкой по сравнению с версией функции менее рискованно. По сути, если версия зависимости обновляет только третье число в версии ('z' в версии xyz), это менее рискованно, чем если бы это была вторая.