Почему динамические диапазоны версий в Maven не так полезны, как предполагалось изначально?

Question

Я всегда использовал явные версии для зависимостей Java в Maven / POM.

Затем на короткое время я переключился на Python, где я узнал, что диапазоны версий зависимостей (например,> = 2.3.0) довольно популярны и, похоже, ограничивают проблемы конфликтов зависимостей: вероятность того, что два диапазона перекрываются, выше две точные версии равны. Я задавался вопросом, почему такого решения не существует в мире Maven / POM?

Затем я получил уведомления об уязвимости в одном из моих зависимостей проекта GitHub и предложение обновить его до:

<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-databind</artifactId>
  <version>[2.9.9,)</version>
</dependency>

Отлично, подумал я, поэтому в Maven есть диапазоны версий зависимостей! Мне не нужно будет обновлять мои зависимости так часто. Но потом я прочитал, что они де-факто извращены , потому что:

• они не так полезны, как первоначально предполагалось , а также то, что они вряд ли получат улучшения без существенного переосмысления.

• и тот

  Разрешение диапазонов зависимостей не должно преобразовываться в моментальный снимок (версия для разработки), если он не включен в качестве явной границы

  но там, похоже, есть ошибка (поднято в 2007 году и вновь открыто в 2018 году).

Почему они не так полезны, как предполагалось изначально?

Существуют ли альтернативные платформы для Java, кроме Maven, которые обрабатывают диапазоны версий зависимостей?

Answer 1

Другой вариант - Gradle .Из документации "Если зависимость объявлена ​​как динамическая версия (например, 1. +, [1.0,), [1.0, 2.0)), Gradle разрешит это до самой высокой доступной конкретной версии (например, 1.2) в хранилище"