Как увеличить номер версии в соответствии с последней утвержденной iOS версией - PullRequest
Новая
       6

Как увеличить номер версии в соответствии с последней утвержденной iOS версией

1 голос
/ 09 марта 2020

Я знаю, что есть increment_version_number полоса, но она увеличивает версию, помещенную в файл Info.plist. Это означает, что после каждой загрузки в TestFlight разработчик должен обновлять Info.plist файл новой версией.

Кроме того, у Fastlane есть get_version_number полоса, но я не смог заставить мой скрипт работать, потому что он не может увеличивать версию, как 2.4.1, с последней ди git.

Итак, как я могу сделать +1 (до последнего di git) до утвержденной версии в TestFlight, которая в настоящее время 2.4.1?

1 Ответ

1 голос
/ 10 марта 2020

Если у вас есть существующая загрузка в Testflight для приложения, вам нужно увеличить либо Version number, либо Build number (или оба).

Version number можно автоматически увеличить с помощью increment_version_number (как вы заметили), но вы должны указать, что увеличивать. В вашем случае (v2.4.1): основной номер версии - 2, младший - 4, патч - 1.

Поэтому вы должны добавить этот фрагмент в Fastfile перед сборкой / архивированием приложения: 

increment_version_number(
  bump_type: "patch"
)

Однако я бы не рекомендовал устанавливать номера версий автоматически, поскольку номер версии приложения зависит от того, что вы указали в обновлении. Если это просто выпуск с исправлением ошибок или оптимизация производительности, то увеличьте последнюю ди git на patch. Если вы добавили несколько интересных новых функций, вы должны увеличить minor версию. Если бы обновление было похоже на переписывание с нуля, полное изменение или внесение каких-то серьезных изменений, то я бы увеличил число major в версии. Не элегантно всегда увеличивать число patch, потому что номер версии имеет значение.

В проекте, над которым я работаю, мы использовали для увеличения номеров версий вручную при выпуске, но увеличивали Build numbers автоматически с Fastlane.

Вот что мы сделали:

1.) Включите Apple Generi c Управление версиями в проекте: (Проект> Настройки сборки> Управление версиями> Система управления версиями: Apple Generi c)

2.) Установите базовый номер сборки: (Проект> Настройки сборки> Управление версиями> Текущая версия проекта: 1)

3.) Добавьте следующий простой помощник Ruby класс в папку fastlane / utility:

changelog_helpers.rb: 

class BuildNumberFactory
  class << self
    def make
      `git rev-list HEAD --count`
    end
  end
end

4.) Добавьте эту строку в самые первые строки в Fastfile: 

Dir.glob('./utility/*').each { |file| require file }

5.) Использование в FastFile: 

lane :your_submit_testflight_lane do
    increment_build_number build_number: BuildNumberFactory.make
    # gym, pilot, other actions after setting the build number
end

Этот метод предполагает, что вы используете Git для контроля версий. В основном для каждого коммита Fastlane может назначить определенный c номер сборки. И поскольку вы загружаете приложения с приращением Build number, не будет проблемой, что Version number не изменится.

Когда вы собираетесь выпустить обновление для приложения, я бы предложил:

1.) Увеличить Version number (ex 2.4.2) в новый коммит, pu sh это на удаленный

2.) Создайте тег Git для этого коммита

3.) Запустите полосу Fastlane, которая загружает сборки в Testflight

При использовании описанной выше техники c разработчикам не придется постоянно обновлять Info.plist Version number при отправке ежедневных тестовых сборок в Testflight. Вам нужно только увеличивать Version number, когда вы выпускаете обновление - вы все равно не сможете этого избежать.

Надеюсь, это поможет! :)

...