Auto update of version_name and version_number feature request

[cmonish]

Hi Team,

I would like to request for a feature to update version_name and version_number for the existing variant when ever a new deployment for testflight has happened.
Currently the version_name or version_number bump was not happening.

Hope I will get a quick solution on this.
Thanks in advance.

[bb-gminucci]

Hi @cmonish thanks for the request. I have a couple questions around it, currently Variants allows the developer to have full control of the app version for each variant through the properties version_name and version_number being injected to the Xcode properties of Version and Build respectively.

My initial thinking on this is that in order to have the capability to automatically update the version number on each release we would require to dynamically change the variants.yml file on each deploy run and have a configuration to define what would be the "version bump" method to be used.

I see a couple challenges here:

• Pipeline would be required to also commit on every deploy to keep track of the version number change
• Developer MUST follow a strict pattern in the version_name and version_number fields otherwise the automatic bump would fail
• do we also consider major releases and hot fixes or only minor releases that bumps the build number?

What are your thoughts on this @arthurpalves and @cmonish ?

[arthurpalves]

I think, based on what Monish wanted to accomplish, this task can be split into two separate proposals.

1. A variants update command that could take the properties it wants to update for a particular variant, such as version_name, version_number.

This will present the challenges you mention above, such as committing the resulting changes if this is used in CI.

2. Here comes the second proposal, and in my opinion the most important.
   For use in CI, we might not need a variants update command at all, and instead rely on a flag of sorts, such as specifying version_number: auto. This will ensure Variants fetches the latest build number from TestFlight and increments by 1. If none returned, reset the count. Committing the changes isn't necessary, since the only place that would contain the actual value is the freshly generated .xcconfig

For this to happen, we'll require the creation of an AppStoreConnect API key and the creation of 3 repository secrets to contain the key_id, issuer_id and key_content.

We will also quickly update our fastlane files to not run the prepare lane in before_all, since we'll have to call fastlane twice in our workflow files and the first time it is completely unnecessary to run prepare.