или почему клиентам нельзя разрешать выбирать коды версий

Чаще, чем вы думаете, меня просят указать номер версии приложения на основе маркетинговых предпочтений или произвольных предпочтений клиента.

Это определенно неправильно по ряду веских причин.

Прежде чем пытаться сказать почему, давайте послушаем, во что я вошел некоторое время назад.

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

Тем временем они распространили приложение среди своих клиентов за пределами официального магазина.

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

В тот момент они не хотели, чтобы я должным образом обновлял номер версии, как я предлагал, утверждая, что приложение раньше никогда не публиковалось в магазине. Я сказал, что вы клиент, но имейте в виду, что с этим могут возникнуть проблемы.

И проблемы вскоре проявились!

Через несколько дней после публикации приложения клиент обратился ко мне с вопросом: можете ли вы сказать мне, почему клиенты, установившие старую версию приложения (ту, которая распространяется вне магазина), не могут обновить ее через магазин?

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

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

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

Поэтому, когда вы устанавливаете версию своего программного обеспечения, всегда будьте осторожны и помните, что, учитывая номер версии major.minor.patch, вы должны увеличивать:

  • патч при исправлении ошибок
  • второстепенный, когда вы вводите новые функции
  • серьезные, когда вы вносите изменения, которые нарушают обратную совместимость или полностью меняют взаимодействие с пользователем

При этом в повседневной практике, если вы хотите начать с этапа разработки перед запуском в производство, самым простым может быть начало с номера версии 0.1.0 и увеличение второстепенных при каждой новой разработке.

Также имейте в виду, что если вы работаете над производственным проектом, всегда рекомендуется начинать с кода версии 1.0.0.