Úprava release managementu about movapp-apple HOT 5 CLOSED

Pokud jde o formát tagů, souhlasím s tím, že můžeme zjednodušit verzování na major.minor, a místo .patch budeme dávat .build, takže můžeme (u tagů!) zachovat stávající systém x.y.z? Celkové workflow:

1. Když začneme pracovat, nastavíme číslo verze, ke které směřujeme (například 1.1, něco jako fastlane bump-marketing-version). Tahle akce by měla pouze nastavit marketingovou verzi pro všechny targety v projektu, nic víc – nic netagujeme, neměníme changelog, etc. (Zároveň bysme měli resetovat číslo buildu na nulu?)
2. Jakmile chceme vydat nový build, pustíme automatizaci, která všude zvedne číslo buildu, aktualizuje a commitne changelog a otaguje commit (v1.1.1, název akce něco jako release). Z pohledu App Storu jde furt o tentýž release (nemění se marketingové číslo verze).
3. Takhle opakujeme, dokud nemáme produkční verzi (1.1.10 třeba). Ta jde do App Storu a my jdeme zpátky na krok (1), tedy postrčíme marketingovou verzi.

Sedí to? Na to nastavení Fastlane můžu mrknout, nic jiného by se myslím měnit nemělo.

from movapp-apple.

1. Souhlas, jenom číslo buildu by se myslím nemělo resetovat a mělo by být "unikátní" - increment https://developer.apple.com/documentation/xcode/setting-the-next-build-number-for-xcode-cloud-builds
2. Souhlas
3. Souhlas, build verze ale musí pokračovat.

Ja si myslím že sedí, @pistelak nějaké points?

from movapp-apple.

tak ten build vypadá že můžeme resetovat :)

from movapp-apple.

Já jsem se teď v rychlosti snažil zjistit, jestli nám App Store sežere třeba 1.1 build 1 a 1.2 build 1, ale než to řešit, klidně nechme to číslo buildu neresetované (tedy například 1.1 build 10, trvalo nám deset buildů vydat 1.1, a následně 1.2 build 15, trvalo nám pět buildů vydat 1.2). Takže efektivně vzato bude číslo buildu naše „vývojářská verze“ a marketingovou verzi můžeme šoupat podle potřeby. Vyrobím.

from movapp-apple.

PS. Ještě jsem pročítal ten dokument odkazovaný Martinem a tam píšou:

For example, your latest app version in the App Store could be 1.2.1 (42) before you start using Xcode Cloud. When you start using Xcode Cloud, your next app version would be 1.2.2 (1) because Xcode Cloud build numbers start at 1. It’s a unique combination of the version and the build number and, as a result, App Store Connect accepts it when you submit the new version for app review.

However, Mac apps must follow different build number requirements. To successfully submit a Mac app to app review, its build number must continuously increase, even across app versions. If the app in the previous example was a Mac app, version 1.2.2 (1) would be invalid because the build number didn’t increase compared to the previous version 1.2.1 (42). A valid build number for this Mac app would be 1.2.2 (43).

Tedy na iOS bychom to číslo buildu asi resetovat mohli, ale klidně bych ho nechal běžet (a budeme mít pro sebe jednoduchý unikátní identifikátor buildu).

from movapp-apple.