Комментарии 7
Спасибо, то что надо для начинающего в этом разбираться!
Почитайте про лимит в versionCode https://developer.android.com/studio/publish/versioning#appversioning чтобы избежать проблем с выкладкой в будущем, там всего лишь integer, т.е. Version код никогда не надо пытаться красиво визуализировать, а лучше сделать монотонно возрастающим при каждой сборке
Раскройте пожалуйста, какие проблемы в будущем вы имеете ввиду?
"монотонно возрастающим при каждой сборке" - что имеется ввиду? Я представил, что есть какая-то настроенная автоматизация, которая при запуске определенных пайплайнов делает commit с инкрементальным повышением versionCode.
С ходу кажется, что то возможно добавит трудностей, когда тестировщики будут работать со сборками их master-и релизных веток, придется внезапно удалять приложение, тк versionCode будет зависеть не от фактической версии приложения, а от очередности сборки.
Нам на практике достаточно повышать его в "ключевых" точках - при фичафризе и при патчах с исправлениями ошибок. А все промежуточные ежедневные сборки имеют один и тот же versionCode и это не доставляет проблем тестировщикам и разработчикам.
Предложенный подход не про красивую визуализацию, а про избавление от необходимости думать как и когда его повышать, он повышается в "ключевых" точках.
Основная проблема может быть достижение этого лимита и заливки такой сборки в google play, после чего скорей всего без общения с саппортом гугла будет проблематично её оттуда удалить.
versionCode и versionName можно расположить в gradle.properties и через аргументы запуска тасок у gradle прокидывать ваше инкремент число из ci например так ./gradlew app:assembleRelease -PversionCode=123, так можно без коммитов решить этот момент
про необходимость делать разными коды или одинаковыми конечно зависит от проекта, где то на это числа завязывают версию базы данных или делают чистку кеша между обновлениями, для тестирования таких кейсов было бы не плохо его разным делать
Понял вас. Спасибо за ответ!
Про достижение лимита: в текущем подходе, чтобы его достичь, грубо говоря, major версия должна стать 210000. Если пользоваться semver, то major версия должна повышаться крайне редко (можно посмотреть на номера версий существующих десятилетиями ЯП). Поэтому достижение кажется почти невероятным.
Спасибо за информацию про возможность указания кодов прямо в команде gradlew, буду иметь ввиду!
На практике не связывался со взаимосвязью версии БД или кэша с версиями приложения. Видел, что подобный функционал делали через хардкод константы-версии прямо внутри модуля. Но согласен, что всякое бывает и имеет право на жизнь.
Спасибо большое за материал! Очень полезно и ёмко.
Про поставки и релизы в мобильной разработке