Диапазон значений в gradle

Каковы возможные способы указания диапазонов версий в зависимостях gradle? Я видел примечание 1. +, но я не нашел документа, который действительно говорит, что возможно, а что нет. Кроме того, я не знаю, могут ли использоваться диапазоны Maven.

Может кто-нибудь дать мне краткий обзор, чтобы я мог понять правила?

Ответ 1

В книге "Gradle Управление зависимостями" указано p. 12 и 13, что помимо + -нотации (2.1. + Означает диапазон от 2.1.0 включительно до версии 2.2.0), вы можете использовать нотацию Ivy для открытых и закрытых интервалов формы

[1.0,2.0]
[1.0,2.0[

а также

[1.0, )

для всех версий начиная с 1.0.

Ответ 2

Предпочтительная альтернатива: укажите диапазон версий, используя нотацию плюща. Вот несколько примеров, скопированных с этой веб-страницы:

[1.0, 2.0]: все версии> = 1.0 и & lt; = 2.0
[1.0, 2.0[: все версии> = 1.0 и & lt; 2.0
[1.0, ): все версии> = 1.0 // avoid. Unbound is dangerous!

Непростая альтернатива: используйте "+" в мажорном, минорном номере или номере патча. У этого подхода есть как минимум две проблемы:

Если вы создаете библиотеку и генерируете файл pom, pom будет несовместим с maven, если вы не примените какой-либо обходной путь для определения версии и предотвращения зависимости pom от использования "+" в элементе версии. Смотрите этот выпуск Grad GitHub.
Значение "+" подвержено путанице. Ну, может и нет, но спросите всех, знают ли все ваши ровесники разницу между 1.1.+ и 1.1+ в зависимости от gradle.

Идеальная альтернатива: вообще избегать динамических зависимостей (используя '+' или диапазоны версий). Вместо этого используйте фиксированную зависимость от версии и часто обновляйте версию с помощью хорошего тестирования. Вот почему:

В старые времена обратная совместимость была священной. Это больше не правда. Новые версии часто перемещают/удаляют/переименовывают классы и функции.
Если ваша зависимость является динамической (особенно с "+" или несвязанным диапазоном), при следующей сборке может быть выбрана новая версия, несовместимая с вашим проектом. Несовместимость может быть обнаружена только в rutime.
Версия X вашей библиотеки, созданная сегодня, может отличаться от версии X вашей библиотеки, созданной завтра, если одна из ее зависимостей является динамической, а новая продакшен версияется в одночасье. Такой уровень неопределенности нежелателен для библиотек.