Поддержание паритета версий между платформами

Поддержание паритета версий между платформами
Поддержание паритета версий между платформами - luferlex @ Unsplash

Я работаю в сфере мобильной разработки и использую семантическое версионирование для версионирования своих релизов. Я поддерживаю одинаковые версии до тех пор, пока новые сборки выходят одновременно для платформ iOS и Android.

Но представьте, что я исправляю ошибку, которая появилась только на iOS. Теперь мне нужно выпустить новую сборку для iOS, поэтому я увеличиваю номер сборки только для версии iOS. Теперь версии между платформами рассинхронизированы.

Как вы поступите,

  1. Выпускать сборку "placeholder" для Android с увеличенной версией только для того, чтобы версии были синхронизированы?

  2. Принять тот факт, что номера версий на разных платформах могут и будут отличаться?

Как вы справляетесь с этим случаем в своей работе? Или это не проблема?

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

Предположим, что 1.4.42 была последней версией, выпущенной для обеих платформ. Когда новая версия «1.4.43» исправляет ошибки только для платформы A, просто не выпускайте и не развертывайте соответствующую версию на другой платформе B. В следующий раз, когда вы выпустите новую версию «1.4.44» для обеих платформ, пользователи платформа B может заметить, что вы пропустили для них версию «1.4.43». Но это не проблема, если вы позаботитесь о том, чтобы записать в свой журнал изменений, что изменения с 1.4.42 на 1.4.43 относятся только к платформе A.

Конечно, когда обе базы кода совершенно разные, их можно рассматривать как два продукта с точки зрения разработчика, и вы можете использовать № 2, но тогда вы, вероятно, не будете заморачиваться синхронизацией версий на любом уровне, поддерживать совершенно разные репозитории и журналы изменений.


LetsCodeIt, 18 января 2023 г., 03:05