Хватит спамить фразу «НЕ ПУШИМ, ИДЕТ РЕЛИЗ!» в общий чат!
Когда у вас десятки активно разрабатываемых библиотек с основным проектом, каждый релиз приложения может превратиться в хаос. Dev-ветки библиотек непрерывно пуляют новые версии в репозиторий, и когда основному проекту нужно выходить в релиз, эти версии перезатирают друг друга. Дальше — ручная заморозка публикаций, тревожные сообщения в общий чат и неизбежные ошибки с версиями в десятках конфигураций.
Выход есть — простое правило: ветка основного проекта должна определять, какие версии библиотек она тянет. Dev — dev-сборки, release — релизные. Автоматически. Без рук.
Типичный Gradle-подход — SNAPSHOT-зависимости. Работает из коробки, но есть нюанс: две dev-ветки библиотеки с одним SNAPSHOT-именем перезатирают друг друга. Воспроизводимость сборок под вопросом.
Более надёжное решение — версионирование с суффиксом ветки. Существуют плагины, которые генерируют версии вида v0.0.1-feature-branch — коллизий нет. CI, зная свою ветку, сам подставляет нужные суффиксы в зависимости. Переключили ветку — зависимости переключились сами.
А как же синхронизация библиотек с основным проектом? Добавляется прогон основного проекта с каждой свежей публикацией библиотеки. Это быстро подсвечивает поломки. Но если правки в библиотеке серьёзные — основной проект всё равно придётся адаптировать вручную. CI здесь — система раннего предупреждения. И да, мощности сборочного сервера должны позволять такие прогоны.
А какие подходы используете вы?