Обновление зависимостей дает вам доступ к их новейшим функциям, исправлениям ошибок и улучшениям. Чтобы обновить зависимости, вам необходимо понять, как Gradle разрешает запрошенные вами версии , связанные с этим риски и шаги, которые вы можете предпринять для снижения этих рисков.
Продумайте свою стратегию обновления
Самый важный шаг к любому обновлению — это анализ рисков. Определите, насколько вам комфортно с каждой обновляемой зависимостью. При определении стратегии обновления необходимо учитывать множество факторов, в том числе:
Создайте библиотеку | Вы создаете приложение, которое пользователи загружают и запускают на устройстве? Или вы создаете библиотеку, чтобы помочь другим разработчикам создавать свои приложения? Если вы создаете приложение, вам следует сосредоточиться на поддержании его актуальности и стабильности. Если вы создаете библиотеку, ваше внимание должно быть сосредоточено на приложениях других разработчиков. Ваши обновления влияют на ваших потребителей. Если вы обновите одну из своих зависимостей, эта версия станет кандидатом на разрешение зависимостей Gradle, что может привести к нарушению использования этой зависимости приложением. Во-первых, минимизируйте зависимости вашей библиотеки, где это возможно. Чем меньше у вас зависимостей, тем меньше влияние на разрешение зависимостей вашего потребителя. Обязательно следуйте семантическому управлению версиями , чтобы указать типы вносимых вами изменений. Например, AndroidX следует семантическому управлению версиями и добавляет схему управления версиями предварительной версии . Старайтесь избегать обновлений Рассмотрите возможность создания версии-кандидата (RC) вашей библиотеки, чтобы пользователи могли протестировать ее заранее. См. рекомендации по обратной совместимости для авторов библиотек , чтобы получить подробную информацию о совместимости двоичного интерфейса приложения (ABI) вашей библиотеки. Используйте интеграционные тесты и инструменты, такие как средство проверки двоичной совместимости, чтобы убедиться, что изменения ABI соответствуют запланированному изменению версии. Если вы выпускаете исправления в Если обновление вашей библиотеки требует критических изменений, которые могут быть особенно болезненными для ваших потребителей, рассмотрите возможность выпуска их как нового артефакта, чтобы старые и новые версии могли сосуществовать и обеспечить более постепенное развертывание. Примечание . Если обновление одной из ваших зависимостей содержит серьезные изменения API, вы, вероятно, захотите обновить его в |
Цикл выпуска | Как часто вы выпускаете свое приложение или библиотеку? Сокращение циклов разработки и выпуска
Более длительные циклы разработки и выпуска
|
Будьте в курсе новейших функций | Вы предпочитаете использовать новейшие доступные функции и API или обновляться только тогда, когда вам нужна функция или исправление ошибок? Рассмотрим компромиссы, связанные с частыми обновлениями. Будущие обновления будут проще (меньше изменений, которые нужно интегрировать), но вы чаще рискуете при обновлении. Тестирование обновлений до предварительных версий (альфа-, бета-версий, кандидатов на выпуск) библиотек может помочь подготовиться к выпуску стабильных версий. |
Новая зависимость | Если вы добавляете новую зависимость, рассмотрите возможность тщательного процесса проверки, который проверит эту библиотеку на предмет всех критериев риска, чтобы убедиться, что они были правильно оценены. Не разрешайте добавлять новые зависимости без проверки. |
Выделенная команда | Есть ли у вас специальная команда разработчиков? Ваши инженеры-программисты поддерживают сборку? Специальная группа часто может уделять больше времени анализу рисков обновления и тестированию новых версий, чтобы убедиться, что сборка работает правильно, прежде чем инженеры начнут использовать новые версии. |
Тип обновления | Некоторые обновления более важны, чем другие. Подумайте, что для вас наиболее важно. Обновления инструментов сборки, такие как Gradle и плагины Gradle, обычно оказывают меньшее влияние на ваших пользователей, и большая часть риска связана с вашей сборкой. Сама сборка помогает проверить эти изменения. Обновления библиотеки и SDK сложнее проверить, и они представляют более высокий риск для ваших пользователей. Плагин Android Gradle (AGP) — инструмент, используемый для создания вашего приложения или библиотеки Android. Это самое важное обновление, которое вы можете сделать, поскольку оно часто включает или обеспечивает повышение производительности, исправления ошибок, новые правила проверки и поддержку новых версий платформы Android. Gradle — вам часто потребуется обновить Gradle при обновлении AGP или другого плагина Gradle. Другие плагины Gradle . Иногда API плагинов Gradle меняется. При обновлении Gradle проверьте наличие обновлений для используемых вами плагинов. Kotlin и Java . Для некоторых библиотек и плагинов требуются минимальные версии Kotlin или Java, или вы хотите воспользоваться новыми языковыми функциями, API или улучшениями производительности. Платформа Android . Play Store требует регулярных обновлений Android SDK. Вам следует протестировать новые версии Android SDK как можно скорее. Некоторые обновления SDK требуют внесения изменений в ваше приложение, например новых разрешений или использования новых API. Библиотеки . Хотите ли вы расставить приоритеты в библиотеках на основе их близости к вашей общей архитектуре?
Android Studio — поддержание актуальности Android Studio дает вам доступ к новейшим функциям и исправлениям ошибок в базовой платформе IntelliJ IDEA, а также к инструментам для работы с новейшими Android SDK. |
Доступный инструмент | Существует множество инструментов и плагинов, которые помогут вам с обновлениями. Такие инструменты, как Dependabot и Renovate, автоматически обновляют версии библиотек в вашей сборке, но обязательно анализируйте результаты на предмет рисков. |
Стратегии для конкретных типов обновлений
Обновление некоторых типов зависимостей может иметь каскадный эффект, требующий обновления других типов зависимостей. Мы обсуждаем отношения между элементами сборки в разделе «Взаимозависимости инструментов и библиотек» .
При обновлении каждого типа компонента учитывайте, как обновление повлияет на другие компоненты в сборке.
Плагин Android Gradle (AGP) | В состав Android Studio входит помощник по обновлению AGP , который может помочь в выполнении этих задач. Если вы используете помощник или выполняете обновление вручную, учтите следующее: Посмотрите примечания к выпуску AGP . Обновите Gradle хотя бы до указанной версии. Обновите Android Studio до версии, поддерживающей выбранную версию AGP. Используйте версии Android Studio и AGP, которые поддерживают Android SDK, который вы хотите использовать. Проверьте совместимость с инструментами сборки SDK, NDK и JDK. Если вы разрабатываете плагин Gradle (для внутреннего или публичного использования), который расширяет или использует данные из AGP, проверьте, нужно ли вам обновить ваш плагин. Иногда AGP устаревает, а затем удаляет API, что приводит к несовместимости с предыдущими плагинами. |
Компилятор Kotlin, язык и среда выполнения | Ознакомьтесь с примечаниями к выпуску Kotlin на предмет известных проблем и несовместимостей. Если вы используете Jetpack Compose:
Если вы используете обработку символов Kotlin (KSP), см. раздел «Краткий старт KSP» для получения сведений о настройке и раздел «Выпуски KSP» для получения информации о доступных версиях. Обратите внимание, что вы должны использовать версию KSP, соответствующую версии Kotlin. Например, если вы используете Kotlin 2.0.21, вы можете использовать любую версию плагина KSP, начинающуюся с 2.0.21, например 2.0.21–1.0.25. Обычно вам не нужно обновлять процессоры KSP (например, компилятор Room , который отображается как зависимость Обновите все остальные плагины компилятора Kotlin, которые вы используете. API плагинов компилятора Kotlin часто меняется между выпусками, и плагины должны использовать совместимый API. Если плагин указан в разделе «Плагины компилятора» , вы должны использовать ту же версию, что и компилятор Kotlin. Для любых других плагинов компиляции проверьте их документацию на предмет соответствующего сопоставления. Обратите внимание, что плагины компилятора, которые не поддерживаются вместе с самим компилятором Kotlin, часто испытывают задержки в выпуске, поскольку они ждут стабилизации API плагина компилятора. Прежде чем обновлять Kotlin, убедитесь, что для всех используемых вами плагинов компилятора доступны соответствующие обновления. Наконец, в некоторых случаях язык Kotlin меняется, что требует обновления кода. Чаще всего это происходит, если вы пробуете экспериментальные функции. Если ваш код не собирается должным образом после обновления компилятора Kotlin, проверьте изменения языка или поломку библиотеки времени выполнения в примечаниях к выпуску Kotlin . |
Плагины компилятора Kotlin | Если вам необходимо обновить плагин компилятора Kotlin, обновите его до соответствующей используемой версии Kotlin. Большинство плагинов компилятора Kotlin либо используют ту же версию, что и компилятор Kotlin, либо начинаются с необходимой версии компилятора Kotlin. Например, если версия плагина 2.0.21-1.0.25, вам необходимо использовать версию 2.0.21 компилятора Kotlin. Изменение версии компилятора Kotlin иногда требует других изменений . |
Библиотеки | Библиотеки — это наиболее часто обновляемая зависимость в вашей сборке. Вы увидите доступные обновления в редакторе Android Studio или при использовании некоторых инструментов и плагинов зависимостей . Некоторые библиотеки указывают минимальный Некоторые библиотеки также указывают минимальную версию Kotlin для использования. Обновите версию Kotlin в файлах сборки, чтобы она была не ниже указанной версии. |
Градл | Иногда в новых версиях Gradle существующие API устаревают, и эти API удаляются в будущих выпусках. Если вы разрабатываете плагин Gradle, обновите его как можно скорее, особенно если этот плагин является общедоступным. Некоторые обновления Gradle требуют поиска новых версий используемых вами плагинов. Обратите внимание, что эти плагины могут отставать в своем развитии, поскольку они обновляются, чтобы соответствовать последним API-интерфейсам плагинов Gradle. Чтобы обновить Gradle:
|
Плагины Gradle | Обновленные плагины Gradle иногда используют новые или измененные API-интерфейсы Gradle, что, в свою очередь, требует обновления Gradle или, возможно, изменения их конфигурации в ваших файлах сборки. В любом случае вы увидите предупреждения или ошибки сборки, указывающие на несовместимость. При каждом обновлении плагинов обновляйте Gradle. |
Android SDK | В состав Android Studio входит помощник по обновлению Android SDK , который может помочь в решении этих задач. Если вы используете помощник или выполняете обновление вручную, учтите следующее: Каждый выпуск Android SDK содержит новые функции и API, исправления ошибок и изменения поведения. Play Store требует обновления вашего Прежде чем обновлять Android SDK, внимательно прочтите примечания к выпуску . Обратите пристальное внимание на раздел изменений поведения, который включает в себя:
Раздел изменений поведения может быть довольно длинным, но будьте внимательны, поскольку он часто содержит важные изменения, которые необходимо внести в ваше приложение. Вам необходимо обновить Чтобы воспользоваться новыми функциями SDK во время разработки и обеспечить совместимость во время сборки, обновите плагин Android Gradle (AGP) и Android Studio. К ним относятся новые и улучшенные инструменты для новых SDK. См. раздел «Минимальные версии инструментов для уровня Android API» . При обновлении Android SDK обновите все используемые библиотеки AndroidX. AndroidX часто использует новые и обновленные API для лучшей совместимости и производительности версий Android SDK. |
Android-студия | Обычно вы можете обновить Android Studio в любое время. Вы можете увидеть сообщения с предложением обновить AGP или обновить Android SDK . Эти обновления настоятельно рекомендуются, но не обязательны. Если позже вы захотите использовать Android Studio для обновления AGP или Android SDK, вы можете найти эти параметры в меню «Инструменты» : |
Ява | Если в вашем приложении Android есть исходный код Java, возможно, вы захотите воспользоваться преимуществами новых API-интерфейсов Java. Каждая версия Android SDK поддерживает подмножество API-интерфейсов Java и языковых функций. AGP обеспечивает совместимость с более ранними версиями Android SDK с помощью процесса, называемого обессериванием . В примечаниях к выпуску Android SDK указано, какой уровень Java поддерживается, а также возможные проблемы. Некоторые из этих проблем могут также повлиять на исходный код Kotlin, поскольку Kotlin имеет доступ к тем же API-интерфейсам Java. Обязательно обратите пристальное внимание на разделы JDK API, которые появляются в разделе поведенческих изменений примечаний к выпуску, даже если у вас нет исходного кода Java. Использование JDK указано в нескольких местах ваших сценариев сборки. Дополнительную информацию см. в разделе «Версии Java в сборке Android» . |
Анализ обновления
Обновление зависимости может привести к рискам в виде изменений API и поведения, новых требований к использованию, новых проблем безопасности или даже изменений лицензии. Например, нужно ли вам:
- Изменить код для изменений API?
- Добавить новые проверки разрешений?
- Создать дополнительные тесты или изменить существующие тесты для изменения поведения?
Учтите, что обновленная вами зависимость обновила версии своих зависимостей. Это может быстро привести к огромному набору изменений.
Если вы используете такой инструмент, как Renovate или Dependabot, для автоматизации обновлений, имейте в виду, что они не выполняют за вас никакого анализа; они обновляются до последних версий библиотеки. Не думайте, что после таких автоматических обновлений все будет работать правильно .
Ключом к успешным обновлениям является анализ обновлений:
- Определите различия в зависимостях до и после обновлений.
- Изучите каждое изменение и определите связанные с ним риски.
- Смягчите риски или примите или отклоните изменения.
Определить различия в зависимостях
Первым шагом в анализе обновления является определение того, как изменяются ваши зависимости. Воспользуйтесь преимуществами системы контроля версий (VCS, например Git) и плагина Dependency Guard, чтобы быстро увидеть изменения. Ваша цель — создать снимок «до» и «после» и сравнить их.
Настройте и создайте свой первый базовый уровень
Прежде чем начать обновление, убедитесь, что ваш проект собран успешно.
В идеале устраните как можно больше предупреждений или создайте базовые показатели, чтобы отслеживать, какие предупреждения вы уже видели.
- Lint: изучите существующие предупреждения о lint и создайте базовый показатель Android lint .
- Котлин-компилятор:
- Включите
-Werror, чтобы рассматривать все предупреждения как ошибки. См. раздел «Как определить параметры» . - Рассмотрите возможность использования таких плагинов, как Kotlin Warning Baseline или Kotlin Warnings Baseline Generator .
- Включите
- Другие инструменты. Если вы используете другие инструменты статического анализа (например, Detekt ), поддерживающие отслеживание базовых показателей, настройте их базовые показатели.
Эти базовые показатели предупреждений облегчают просмотр новых предупреждений, появляющихся при обновлении зависимостей.
Создайте базовый уровень зависимостей, настроив и запустив Dependency Guard. В каталоге версий gradle/libs.versions.toml добавьте:
[versions]
dependencyGuard = "0.5.0"
[plugins]
dependency-guard = { id = "com.dropbox.dependency-guard", version.ref = "dependencyGuard" }
И добавьте следующее в файл сборки вашего приложения:
Котлин
plugins {
alias(libs.plugins.dependency.guard)
}
dependencyGuard {
configuration("releaseRuntimeClasspath")
}
классный
plugins {
alias(libs.plugins.dependency.guard)
}
dependencyGuard {
configuration('releaseRuntimeClasspath')
}
Конфигурация releaseRuntimeClasspath является вероятной целью, но если вы хотите использовать другую конфигурацию, запустите ./gradlew dependencyGuard без указанной конфигурации в файле сборки, чтобы просмотреть все доступные конфигурации.
После установки запустите ./gradlew dependencyGuard , чтобы создать отчет в app/dependencies/releaseRuntimeClasspath.txt . Это ваш базовый отчет. Передайте это в свою систему контроля версий (VCS), чтобы сохранить.
Имейте в виду, что Dependency Guard фиксирует только список зависимостей библиотеки. В ваших файлах сборки есть и другие зависимости, например версии Android SDK и JDK. Привязка к вашей VCS до изменения зависимостей позволяет вашему диффу VCS также выделить эти изменения.
Обновите и сравните с базовой версией
Получив базовый уровень, обновите зависимости и другие изменения сборки, которые вы хотели протестировать. На этом этапе не обновляйте исходный код или ресурсы.
Запустите ./gradlew lint , чтобы увидеть новые предупреждения или ошибки lint. Устраните все важные проблемы, а затем обновите базовый уровень предупреждений, запустив ./gradlew lint -Dlint.baselines.continue=true . Если вы использовали другие инструменты для сбора базовых показателей предупреждений, такие как Kotlin Warning Baseline или Kotlin Warnings Baseline Generator , устраните новые предупреждения и также обновите их базовые показатели.
Запустите ./gradlew dependencyGuard , чтобы обновить базовый отчет. Затем запустите разницу VCS, чтобы увидеть изменения, не относящиеся к библиотеке. Вероятно, в него будет включено гораздо больше обновлений библиотеки, чем вы думали.
Анализируйте риски
Как только вы узнаете, что изменилось, рассмотрите возможные риски каждой обновленной библиотеки. Это помогает сосредоточить ваше тестирование или более глубокое исследование изменений. Определите набор рисков для анализа вашего проекта, чтобы обеспечить последовательный анализ.
Некоторые соображения:
Основные ошибки версии | Изменился ли основной номер версии? Когда вы увидите это, обратите особое внимание на затронутые библиотеки при рассмотрении любого из следующих соображений. Если в вашем коде используются какие-либо экспериментальные API (которые часто требуют вашего согласия с использованием аннотаций или спецификаций файла сборки), даже незначительные изменения или изменения версий исправлений, такие как обновление с 1.2.3 до 1.3.1 или с 1.2.3 до 1.2. 5, может представлять дополнительные риски. |
Нестабильный API | Некоторые выпуски библиотек могут включать нестабильные API. Обычно это API, работа над которыми еще ведется или которые зависят от другого нестабильного API. Хотя обычно они ограничиваются предварительными версиями, такими как альфа-версии, версии для разработчиков или экспериментальные версии, некоторые библиотеки включают API-интерфейсы, помеченные как экспериментальные или нестабильные. Если возможно, избегайте таких API. Если вам необходимо их использовать, обязательно записывайте свое использование и следите за изменениями или удалениями в последующих выпусках. |
Динамическое поведение | Некоторые библиотеки ведут себя по-разному в зависимости от внешних факторов. Например, библиотека, которая взаимодействует с сервером, зависит от изменений на этом сервере.
|
Объединение манифеста | Библиотеки, опубликованные как архивы Android (AAR), могут содержать ресурсы и манифесты, объединенные в ваше приложение. Они могут добавлять новые разрешения и компоненты Android, такие как действия или приемники вещания, которые запускаются косвенно. |
Обновления среды выполнения | Некоторые библиотеки используют функции, которые можно обновлять вне контроля вашего приложения. Библиотека может использовать Play Services, которые обновляются независимо от Android SDK. Другие библиотеки могут привязываться к службам в независимо обновляемых внешних приложениях (часто с использованием AIDL). |
Сколько версий вы пропускаете? | Чем дольше вы ждете обновления библиотеки, тем больше потенциальных рисков. Если вы видите, что версия значительно изменилась, например с 1.2.3 на 1.34.5, обратите особое внимание на эту библиотеку. |
Руководства по миграции | Проверьте, есть ли в библиотеке руководство по миграции. Это может значительно сократить объем анализа рисков и планирования их смягчения. Обратите внимание, что наличие такого руководства является хорошим показателем того, что разработчик сосредоточил внимание на совместимости и предусмотрел меры по снижению риска при обновлении. |
Примечания к выпуску | См. примечания к выпуску (если они предусмотрены) для каждой измененной библиотеки. Ищите признаки критических изменений или новых требований, таких как добавленные разрешения. |
README-файлы | В некоторых файлах README для библиотеки отмечаются потенциальные риски, особенно если библиотека не предоставляет примечания к выпуску. Ищите _известные проблемы_, особенно известные проблемы безопасности. |
Проверьте известные уязвимости | Индекс Play SDK отслеживает уязвимости для многих популярных SDK. Play Console сообщает, используете ли вы один из перечисленных SDK с известными уязвимостями. При редактировании файлов сборки в Android Studio IDE проверяет индекс SDK и помечает использование уязвимых версий библиотеки. Национальный институт стандартов и технологий (NIST) ведет большую Национальную базу данных уязвимостей (NVD) . Плагин Dependency Check Gradle проверяет используемые вами зависимости на соответствие NVD. Чтобы использовать проверку зависимостей, запросите ключ API NVD , настройте плагин Gradle и запустите |
Конфликты версий | Версии разрешаются должным образом? Ищите конфликты, особенно существенные различия версий. Подробную информацию о том, как искать конфликты, см. в разделе Разрешение зависимостей Gradle. В частности, найдите По возможности работайте с авторами зависимостей, чтобы устранить конфликты между их зависимостями. Если ваша компания позволяет, внесите изменения в библиотеку (восходящий поток), чтобы улучшить совместимость библиотеки. |
Проверить лицензии | Следите за изменениями в лицензиях при обновлении библиотеки. Лицензия самой библиотеки может быть изменена на лицензию, которая больше не совместима с вашим приложением или библиотекой. Новые транзитивные зависимости могут также привести к появлению несовместимых лицензий. Подробную информацию о проверке текущего набора лицензий в ваших зависимостях см. в разделе Проверка лицензий . |
Техническое обслуживание и | Для библиотек с публичными репозиториями:
|
Открытый и закрытый исходный код | Если библиотека имеет открытый исходный код, отлаживать проблемы будет проще, чем с закрытым исходным кодом, независимо от того, связаны ли проблемы с вашим кодом или кодом библиотеки. Минимизируйте зависимости с закрытым исходным кодом и применяйте дополнительную проверку во время их оценки. Есть ли хорошие альтернативы, подходящие для вашего случая использования? Какие соглашения об уровне обслуживания доступны для библиотек с закрытым исходным кодом? Если вы решите использовать зависимость с закрытым исходным кодом, будьте готовы написать дополнительные тестовые примеры, чтобы ограничить риски. |
Запустить сборку
Создайте свой проект. Ищите новые ошибки или предупреждения. Если вы можете определить, какая библиотека их вызывает, обратите внимание на это как на риск при обновлении этой библиотеки.
Если вы видите какие-либо новые предупреждения об обесценивании, добавьте их как особые риски для библиотеки, создающей их. Их можно будет удалить в более поздних версиях. Если вы хотите продолжать использовать эту библиотеку, посвятите время переходу от использования устаревших API к их замене или обратите внимание на устаревание, чтобы следить за этими функциями и следить за тем, будут ли они впоследствии удалены.
Используйте lint для обнаружения проблем API
Android lint может выявить множество проблем в вашем приложении, в том числе некоторые из них, возникающие в результате изменения версий зависимостей или Android SDK. Например, если вы обновите свой compileSdk и используете его новые API, lint сообщит о тех, которые недоступны в предыдущих версиях SDK.
Lint работает в редакторе Android Studio и сообщает о проблемах по мере внесения изменений. Но обычно он не запускается как часть сборки в Studio или при запуске сборки из командной строки, если только вы не используете цели build или lint .
Если вы используете непрерывную интеграцию (CI), запускайте gradlew build или gradlew lint во время CI-сборок (или, по крайней мере, при ночных сборках), чтобы выявить ошибки такого типа.
Если вы не используете CI, обязательно хотя бы изредка запускайте gradlew lint .
Обратите особое внимание на ошибки и предупреждения lint. Некоторые библиотеки поставляются с собственными проверками на соответствие, что помогает обеспечить правильное использование их API. Некоторые новые версии библиотеки включают новые предупреждения и ошибки lint, что приводит к созданию новых отчетов при сборке.
Снижение рисков
Определив риски обновления, решите, как вы хотите их снизить:
- Примите некоторые риски как есть. Некоторые риски достаточно низки, чтобы быть приемлемыми, особенно когда время обновления и ресурсы ограничены.
- Полностью отвергайте некоторые риски. Некоторые обновления могут показаться слишком рискованными, особенно если на данном этапе у вас ограничено время или ресурсы для их смягчения. Если вам нужно провести сортировку, сосредоточьтесь на обновлениях, необходимых для устранения обнаруженных вами ошибок или новых функций, которые вам нужны.
- Смягчить оставшиеся риски
- Рассмотрите возможность группирования обновлений в более мелкие независимые наборы изменений. Это снижает общий риск и позволяет выполнить частичный откат.
- Подробно изучите изменения.
- Протестируйте свое приложение , чтобы проверить наличие неожиданных изменений. Добавьте новые тесты там, где это необходимо, чтобы повысить уверенность в обновлении.
- Посмотрите на источник (если он доступен), если обнаружите что-то сомнительное.
- Внесите необходимые изменения в исходный код или сборку.
Документируйте свои решения. Если риски, связанные с обновлением, становятся проблемами при запуске вашего приложения, документирование вашего анализа рисков может уменьшить необходимый анализ ошибок.
Проверка лицензий
Разработчики библиотек лицензируют библиотеки для вашего использования. Вы обязаны соблюдать условия лицензии, иначе вы не сможете использовать библиотеку. Некоторые лицензии очень либеральны и часто требуют только указания имени библиотеки и предоставления текста ее лицензии конечным пользователям. Некоторые считаются вирусными ; если вы используете эти библиотеки, вы должны применить ту же лицензию к своему приложению или библиотеке.
Лицензии могут меняться с любым выпуском. При каждом обновлении вам следует убедиться, что используемые вами зависимости лицензированы и совместимы с вашим приложением или библиотекой.
Если лицензия несовместима (или была изменена и стала несовместимой), вы не сможете использовать эту версию библиотеки. Ты можешь:
- Обратитесь к владельцу библиотеки и запросите продление существующей лицензии или двойное лицензирование, чтобы сохранить старую лицензию.
- Поработайте со своей командой юристов, чтобы определить, можете ли вы изменить свою лицензию, чтобы она стала совместимой.
- Найдите другую библиотеку с совместимой лицензией и измените свое приложение по мере необходимости.
- Создайте форк последней совместимой версии библиотеки (если эта лицензия допускает производные и изменения не имеют обратной силы) и внесите свои собственные изменения.