Základy verzování softwaru

1. Co se stane, když se verze neřeší

Když aplikaci vyvíjíte, vznikají nové funkce, opravují se chyby a mění se chování. Může se zdát zbytečné změny nějak značit, vždyť nyní je přece jasné, co má aplikace za funkce a jak funguje.

Jenže je třeba myslet do budoucna. Můžete se sice orientovat podle data instalace, ovšem z hlediska dohledatelnosti je to příliš vágní údaj, protože se může, ale nemusí shodovat s datem vydání.

2. Co získáte správným verzováním

Číslo verze je jednotící údaj mezi vývojem, podporou a zákazníkem. Když někdo někomu nahlásí číslo verze, zúčastněné strany vědí, o jakém stavu aplikace se baví.

Pokud verzujete správně, pak umíte jednoduše dohledat, co se ve které verzi změnilo, kdy byla vydaná, kde je instalovaná a jestli je bezpečné z ní udělat rollback.

3. Jaká schémata značení existují

Sémantické verzování, tzv. SemVer, používá tři čísla MAJOR.MINOR.PATCH — major hodnotu zvyšujete při nekompatibilní změně, minor při nové funkci a patch při opravě. Hodí se všude, kde záleží na kompatibilitě, typicky u knihoven a veřejných API.

Kalendářní verzování, tzn. CalVer, kóduje do označení verze datum vydání, například 2026.08 nebo 2026.08.2. Vyhovuje aplikacím s pravidelným vydáváním, kde zákazníka nezajímá kompatibilita, ale stáří verze.

Nejjednodušší verzování je označení verze přímo číslem buildu nebo sekvencí, která se s každým vydáním zvyšuje. Interním nástrojům a automatizovaným buildům to většinou stačí, pro člověka je však toto značení anonymní, protože z něj nepozná ani datum vydání, ani případně nekompatibilní změny.

Často se používají kombinace těchto schémat, například SemVer s datem vydání v popisku nebo CalVer s číslem buildu. Verze se také uvozují písmeny, například v1.2.3 nebo 2026.08.2b a mohou se přidávat i další informace, například o stavu vývoje (alpha, beta, rc) nebo o platformě (android, ios).

4. Co k takovému verzování potřebujete

Pokud máte své zdrojové kódy v Githubu, GitLabu nebo Bitbucketu, můžete využít jejich nástroje pro značkování verzí. V GitHubu k tomu slouží tzv. Tagy, které přiřadí verzi ke konkrétnímímu commitu.

Ke každé verzi je dobré vést tzv. Changelog — čitelný seznam změn pro lidi nebo AI, oddělený od samotné historie commitů. Může se jednat o jednoduchý textový soubor, ale existují i nástroje, které z commitů generují changelog automaticky.

5. Kdy stačí verzování bez automatizace

Ne každý produkt potřebuje CI/CD automatizované verzování. Jednoduché produkty nebo aplikace vydávané v pravidelných dlouhých intervalech (např. na měsíční, půlroční nebo roční bázi) si často vystačí s tím, že verzi zapíšete ručně ve chvíli, kdy ji skutečně vydáte.

V aboutthe.app jde u takových produktů vést historii verzí přesně tímto způsobem — ručně přidat číslo verze a změny v této verzi. Přehled verzí a jejich změn je pak dostupný všem, kdo mají k produktu přístup.