Вам следует использовать бета-версии AndroidX

Знаете ли вы, что версионирование библиотек AndroidX и их гарантии стабильности отличаются от большинства библиотек? Их бета-версии и релизы-кандидаты фактически готовы к использованию в продакшене, и вам стоит их использовать!

В «обычной» библиотеке, такой как те, что выпускаю я, добавляются функции и исправляются известные ошибки для создания стабильного релиза, который может быть выпущен как версия 1.2.0. Если в этом релизе обнаруживаются какие-либо ошибки, они исправляются и переносятся в версию 1.2.1. При добавлении новых API следующая версия становится 1.3.0. Это базовое семантическое версионирование.

AndroidX не использует такоt именование версий. Когда в библиотеку добавляются функции и исправляются известные ошибки, они повышают её до версии beta01. Этот артефакт теперь имеет стабильную версию API! Не верите? Это задокументировано в их руководстве. У них даже есть инструменты, которые подтверждают невозможность изменить API или даже добавить новые API после того, как артефакт достиг бета-версии.

Таким образом, когда AndroidX выпускает версию 1.2.0-beta01 какой-либо библиотеки, это эквивалентно выпуску обычной библиотеки версии 1.2.0. Это всё ещё семантическое версионирование, но более строгий вариант, накладывающий ограничения на предварительные версии.

Зачем это делается? Мотивация проста: разработчики Google хотят, чтобы стабильные версии были максимально стабильными. То есть, чтобы большинство ошибок, которые в противном случае потребовали бы последующих выпусков патчей, были устранены при переходе к версии 1.2.0.

Вот все эти слова в виде диаграммы:

Вам интересно, использует ли кто-нибудь эти бета-версии? Все собственные приложения Google поставляются с кодом из HEAD-файла AndroidX. Они не только полагаются на эти бета- и RC-версии, но и собирают, тестируют и поставляют альфа-версии, а также случайные коммиты между ними. К тому времени, как библиотека достигает версии -beta01, она уже широко протестирована и развернута. AndroidX для приложений Google — то же, что все ваши util- и common-модули для вашего приложения: общий код, являющийся частью их кодовой базы.

Раньше в Cash App нам приходилось время от времени переходить на бета-версию, чтобы обойти ошибку или получить доступ к новой функции.

• В стабильной версии библиотеки графических фигур была ошибка, из-за которой нарушались скругленные углы оформления нашего bottom sheet
• В примитивных специализациях библиотеки коллекций ScatterMap была ошибка, из-за которой при вставке возвращались удаленные значения
• Несколько проблем Compose, будь то проблемы рантайма, foundation или UI, связанные с проблемами рекомпозиции, проблемами компоновки, проблемами сохраненного состояния и т.д.

Во всех этих случаях мы сообщали об ошибках (или находили существующие) и переходили на бета-версии или релизы-кандидаты следующей версии.

Придерживаться стабильных версий — это легко, но и за это приходится платить. Один из компромиссов, на который пришлось пойти, выбрав такой подход к выпуску стабильных версий, заключается в том, что стабильные версии значительно отличаются друг от друга. Допустим, вы используете Compose UI 1.8 и обнаруживаете ошибку при переходе на Compose UI 1.9. Вы не только застреваете на версии 1.8 (при условии отсутствия обходного пути), но и вынуждены месяцами ждать Compose UI 1.10. И надеетесь, что цикл не повторится. Однако, если вы обнаружили ту же ошибку в бета-версиях Compose UI 1.9, то она будет исправлена ​​через несколько недель, и вы сможете обновиться на несколько месяцев раньше.

Это не означает, что вы сразу же столкнётесь с хаосом предрелизных версий в сотнях библиотек AndroidX. Вы можете постепенно пробовать это — именно этим мы и занимаемся. Зрелые библиотеки (коллекции, ядро, активити и т. д.) предполагают, что изменений происходит немного, поэтому риск невелик. Библиотеки с высокой нагрузкой (среда выполнения Compose, foundation и UI) также являются хорошими кандидатами, поскольку вам действительно нужно как можно скорее найти в них любые ошибки.

Если вы создали необходимую инфраструктуру тестирования, вы уже готовы к этому и можете использовать бета-версии с уверенностью. Комплексные модульные тесты гарантируют корректное поведение. Тесты с использованием скриншотов гарантируют корректность пикселей. А инструментальные тесты, сквозные тесты и/или ручное тестирование качества — это гарантия надежности, гарантирующая, что ничто не ускользнет от внимания.

В любом случае, как пользователи библиотеки AndroidX, мы несём общую ответственность за сообщение об ошибках в процессе разработки, чтобы они были исправлены. Нельзя рассчитывать, что их обнаружит кто-то другой. В Cash App у нас очень большая кодовая база, и мы делаем много интересного с помощью этих библиотек. Чтобы максимально эффективно использовать бета-версии, мы планируем продолжать выявлять и сообщать о любых найденных ошибках. Это поможет нам не только поддерживать возможность обновления, но и всем остальным, кто использует эти библиотеки. И, кстати, думаю, вам стоит поступить так же!

Источник