Verzování aplikací: schémata, příklady a postupy
Verzování aplikací je přidělování jednoznačného označení každému vydání aplikace. Díky tomu umíte dohledat co obsahuje, kdy aplikace vyšla a třeba také kde běží.
Shrnutí a kontext
„Jakou verzi aplikace máte?“ „No, tu poslední...“ — tak tohle je odpověď, po které víte přesně tolik jako předtím. Projděme si rozdílné přístupy k verzování, řekněme si rozdíl mezi verzí a číslem buildu, a zkusme si ukázat místa, kde by měla být verze vidět. Možná se pak podobným odpovědím vyhnete.
1. Co je verzování aplikací a proč na něm záleží
Číslo verze je společná značka vývoje, podpory a zákazníka. Když zákazník řeší problém nebo poptává novou funkci, vychází z verze aplikace, kterou má nainstalovanou. A pro vývojáře a podporu je to klíčová informace.
Bez verzí se můžete orientovat podle data instalace, můžete hledat v historii nasazení CI/CD nebo v úkolech v ticketovacím systému. To ale není ani spolehlivé, ani rychlé řešení.
2. Schémata verzování: SemVer, CalVer a pořadové číslo
Sémantické verzování (SemVer) používá tři čísla MAJOR.MINOR.PATCH. Každá část nese informaci o povaze změny, takže už z čísla poznáte, o jak velkou změnu jde.
| Schéma | Formát | Kdy se hodí |
|---|---|---|
| SemVer | MAJOR.MINOR.PATCH, např. 2.4.1 | Knihovny, veřejná API, cokoliv, co používají třetí strany a vyžaduje zpětnou kompatibilitu |
| CalVer | RRRR.MM(.pořadí), např. 2026.10.2 | Pravidelně vydávané aplikace, kde záleží na stáří aplikace |
| Pořadové číslo | Rostoucí celé číslo, např. 482 | Interní nástroje, automatizované buildy |
3. Kalendářní verzování a pořadové číslo
Kalendářní verzování (CalVer) kóduje do verze datum vydání, například 2026.10 nebo 26.10.2. Hodí se pro aplikace s pravidelným režimem vydávání (releasu), kde uživatele nezajímá kompatibilita, ale stáří, respektive aktuálnost. Z čísla totiž uživatel hned pozná, že verze 25.01.1 vyšla již na začátku roku 2025.
Nejjednodušší je pořadové číslo, které se s každým vydáním zvýší o jedna. Automatizovaným buildům a interním nástrojům stačí, člověk z něj ale nepozná datum vydání ani nekompatibilní změnu. Proto se obvykle kombinuje s jedním z předchozích schémat.
4. Příklady: jak se číslo verze mění
Stejná historie verzí vypadá v každém schématu jinak. V tabulce vidíte, jak se číslo verze mění v jednotlivých schématech.
Často se můžete setkat s tím, že ke třem číslům SemVer se přidávají nejrůznější přípony. Například, předběžná vydání se značí pomlčkou (2.0.0-beta.1, 2.0.0-rc.1) a mají nižší prioritu než finální 2.0.0. Anebo metadata buildu, která se uvádějí za znaménkem plus (2.4.1+482), nesou doplňující údaj a prioritu verze neovlivňují.
| Vydání | SemVer | CalVer (RR.MM.pořadí) |
|---|---|---|
| První veřejná verze | 1.0.0 | 26.08.0 |
| Oprava chyby | 1.0.1 | 26.08.1 |
| Nová funkce | 1.1.0 | 26.09.0 |
| Další oprava ve stejném měsíci | 1.1.1 | 26.09.1 |
| Nekompatibilní změna API | 2.0.0 | 26.10.0 |
5. Verze vs. číslo buildu u mobilních aplikací
Mobilní platformy rozlišují dvě hodnoty: verzi, jakožto text, který uvidí uživatel v obchodě s aplikacemi, a číslo buildu, jež je technický údaj, podle kterého obchod pozná, že nahraný balíček je novější než předchozí.
Na Androidu jde o versionName (libovolný text, např. 2.4.1) a versionCode (kladné celé číslo, které musí s každým nahráním do Google Play růst). Na iOS jde o CFBundleShortVersionString (verze ve tvaru tří čísel oddělených tečkou) a CFBundleVersion (číslo buildu, v Xcode jako MARKETING_VERSION a CURRENT_PROJECT_VERSION).
Uživatel nahlásí verzi 2.4.1, ale ta mohla vyjít ve třech buildech. Pokud podpora vidí jen verzi, pak nepozná, který build uživatel skutečně má. Pokud verzi pravidelně neměníte spolu s číslem buildu, pak i číslo buildu patří vedle verze na obrazovku „O aplikaci“ a do systémových logů.
| Platforma | Verze pro lidi | Číslo buildu |
|---|---|---|
| Android | versionName = "2.4.1" | versionCode = 482 |
| iOS | CFBundleShortVersionString = 2.4.1 | CFBundleVersion = 482 |
| Flutter (pubspec.yaml) | version: 2.4.1+482 (část před +) | část za + |
| Expo (app.json) | version | android.versionCode, ios.buildNumber |
6. Kde má být verze vidět
Číslo verze schované ve zdrojovém kódu většinou nikomu nepomůže. Verzi uvádějte všude, kde potřebujete rozlišit stáří aplikace, tzn. nejčastěji se jedná o různé systémové a transakční logy, API volání, definice rozhraní a konfigurace. Zobrazte číslo verze i v uživatelském rozhraní: v nastavení aplikace, v patičce webu nebo na obrazovce O aplikaci. Myslete na to, že verzi musí umět jednoduše zjistit konzultant, tester i běžný uživatel.
V AboutTheApp tuto roli plní About box. Vložíte ho do aplikace jednou a zobrazuje aktuální verzi přímo v provozu. Když mu v atributu version předáte verzi z buildu, ukáže přesně tu verzi, která běží, i když novou verzi v AboutTheApp nikdo nezapsal. Z About boxu vede odkaz na veřejnou About page s historií verzí k aplikaci a seznamem změn.
S verzí udržujte i tzv. changelog — seznam změn, který je dostupný pro uživatele aplikace, s poznámkami k vydání ke každé verzi. Jak takový přehled vypadá, ukazuje záložka Verze produktu na About page samotného AboutTheApp.
7. Verze u různých zákazníků
Jakmile aplikace běží u více zákazníků nebo ve více prostředích, většinou už nestačí vědět, jaká je jedna nejnovější verze. Konkrétní zákazník totiž bude mít nějakou verzi na produkci, ale jinou na stagingu a u dalších zákazníků takto mohou být nainstalovány verze různého stáří. Samozřejmě, že ideálně se budete snažit mít všechny zákazníky na co nejnovější verzi, protože udržovat zastaralé instalace je náročné a rizikové. Ale v praxi, především v přechodném období při vydání nové verze, je takový stav běžný.
V AboutTheApp vedete u každého produktu katalog verzí s changelogem a ke každému zákazníkovi a prostředí nasazení s konkrétní verzí, URL a umístěním. Na dashboardu pak u produktu vidíte nasazení po zákaznících a označení zastaralých instalací, takže hned poznáte, kdo běží na staré verzi.
Verze i nasazení můžete zapisovat ručně v dashboardu, ale lépe je synchronizovat je přímo z CI/CD vašeho repozitáře. Zákazník pak na své About page v záložce Prostředí a verze vidí stav svých prostředí včetně historie nasazení.
Každá verze má svou viditelnost, může být veřejná nebo privátní. Privátní verze vidíte jen vy nebo ověřený uživatel, veřejné se zobrazí všem.
8. Osvědčené postupy
Žádné schéma není univerzálně nejlepší. Důležitější než volba schématu je, aby celý tým dodržoval stejnou konvenci verzování a neměnil ji během životního cyklu aplikace.
Časté otázky
Co znamená číslo verze aplikace?
Číslo verze označuje jedno konkrétní vydání aplikace. U SemVer, například 2.4.1, první číslo značí nekompatibilní změny, druhé nové zpětně kompatibilní funkce a třetí opravy chyb. U CalVer číslo říká, kdy vydání vyšlo, například 26.10 pro říjen 2026.
Jaký je rozdíl mezi číslem verze a číslem buildu?
Číslo verze je určené lidem a říká, jaké vydání aplikace používají, například 2.4.1. Číslo buildu identifikuje konkrétní sestavení a u mobilních aplikací ho vyžaduje obchod, například versionCode na Androidu nebo CFBundleVersion na iOS. Jedna verze tak může mít více buildů.
Kdy zvýšit major verzi?
Podle pravidel SemVer při každé změně, která není zpětně kompatibilní: odebrané nebo přejmenované API, změněný formát dat nebo chování, na které se spoléhají konzumenti vaší aplikace. Prakticky tím říkáte, že při posunu major verze se mění nějaká pravidla a očekávání, která budou muset konzumenti vaší aplikace zohlednit ve svých aplikacích. Minor a patch se pak vynulují, z 1.7.3 je 2.0.0.
Mám použít SemVer nebo CalVer?
SemVer, pokud je na vaší aplikaci závislá jiná aplikace nebo když záleží na kompatibilitě, typicky u knihoven a veřejných API. CalVer, pokud vydáváte pravidelně a uživatele zajímá hlavně stáří aplikace, typicky u webových a interních aplikací.
Můžu začít verzí 0.x?
Ano. SemVer vyhrazuje verze 0.x pro počáteční vývoj, kdy se aplikace nebo rozhraní může kdykoliv změnit. Verzi 1.0.0 použijte ve chvíli, kdy aplikaci už používají skuteční uživatelé, protože od té chvíle se zavazujete ke kompatibilitě.
Musí mít všichni zákazníci stejnou verzi?
Nemusí, je běžné, že je v provozu více verzí jedné aplikace u různých zákazníků. Reálně také bude jiná verze v produkčním prostředí a jiná (novější) na testovacím prostředí. Zákazníci často aktualizují své aplikace dle svých pravidel a možností, takže mít přehled o nasazených verzích je užitečné.
Moje aplikace se skládá z více služeb, mám oddělený backend a frontend. Jak mám verzovat jednotlivé části?
Záleží, jakým způsobem organizujete vývoj a nasazení jednotlivých částí aplikace. Obecně platí, že každá služba, modul nebo část, která je nasazována samostatně, by měla mít vlastní verzi. Pokud však je aplikace v tzv. monorepu a všechny její části nasazujete společně, není problém mít jednu společnou verzi pro celou aplikaci.
Mám aplikaci, která už má spoustu funkcí, ale nikdy jsem ji neverzoval. Nyní ji chci začít verzovat. Jak začít? Je nutné rekonstruovat historii verzí?
Není nutné rekonstruovat historii verzí. Vyberte si schéma verzování a vydejte svoji první verzi. Nové změny v aplikaci pak začnete sledovat od tohoto bodu. Pokud aplikace prošla zásadními změnami, které považujete za vhodné zdokumentovat, můžete zpětně přiřadit verze k těmto změnám.
Ve zkratce
Verzování aplikací je jednoduché pravidlo s jednoduchým principem: jedno schéma, každá verze unikátní a ke každé vést seznam změn.
Chcete mít verze a nasazení na jednom místě?
Založte si v AboutTheApp svoji aplikaci, přidejte k ní verzi s popisem změn a přiřaďte ji svým zákazníkům a jejich prostředím.