# Wydania i podpisywanie

Każde wydanie wycinasz z `main`. Tytuł PR-a w konwencji conventional-commit decyduje o kolejnej wersji, a jeden workflow buduje, podpisuje i publikuje binarki dla macOS i Windows, gdy tylko ta wersja zostanie ustalona.

## Branching i PR wydania

Pracujesz na `dev` i scalasz do `main` przez PR. Gdy tytuł PR-a jest zgodny z konwencją `feat|fix|chore|docs|style|refactor|perf|test|build|ci|revert`, release-please czyta historię commitów na `main` i otwiera lub aktualizuje PR wydania z kolejną wersją i changelogiem. Scalasz ten PR, a on tworzy szkic GitHub Release wraz z tagiem. Commity `chore` nie podnoszą wersji, więc żeby wyciąć wydanie, trzeba poprawnie używać pozostałych typów commitów.

Przy hotfiksie pomijasz normalny przepływ:

1. Utwórz branch `hotfix/<opis>` z `main`.
2. Wprowadź tylko jeden commit `fix(scope): ...`.
3. Scal go. Dzięki temu release-please otworzy PR podnoszący wersję patch.
4. Przenieś fix z powrotem do `dev` przez cherry-pick.

Po opublikowaniu wydania `dev` jest resetowany do stanu `main`, żeby oba branche się nie rozjeżdżały.

## Od tagu do opublikowanych binarek

Gdy scalisz PR wydania, uruchamia to workflow wydania aplikacji desktopowej, opisany w całości na stronie [CI/CD](/pl/docs/contributing/ci-cd/). Buduje on aplikację dla macOS Apple Silicon, macOS Intel i Windows, kompiluje krzyżowo CLI dla trzech platform docelowych, podpisuje pliki wyjściowe aktualizatora Tauri i wysyła każdy element do szkicu wydania. Skrypt weryfikacyjny sprawdza potem, czy szkic zawiera pełny oczekiwany zestaw podpisanych i niepodpisanych elementów, zanim przełączy go w żywe wydanie.

[Aktualizacje trafiają do użytkowników jednym stabilnym kanałem, udostępnianym przez GitHub Releases.](/pl/docs/guides/updates-and-recovery/) Mechanizm aktualizacji porównuje wersje i przesuwa użytkowników wyłącznie do przodu: nie ma API do cofania wersji.

## Podpisywanie kodu i autentyczność binarek

Każdy plik Mach-O dołączony do aplikacji macOS, w tym CLI, Node.js i helpery napisane w Swifcie, podpisujesz osobno certyfikatem Developer ID Application, z Hardened Runtime i bezpiecznym znacznikiem czasu, a potem zlecasz notaryzację całej paczki w Apple, zanim trafi do użytkowników. Podpisy aktualizatora Tauri używają osobnego klucza Ed25519. Strona [Autentyczność binarek](/pl/docs/security/binary-authenticity/) tłumaczy, przed czym chroni każda z tych warstw i dlaczego to właśnie certyfikat Developer ID chronisz najbardziej.

Podpisywania kodu dla Windows jeszcze nie wdrożyłeś. Zamiast lokalnego pliku certyfikatu użyjesz Azure Artifact Signing (podpisywania w chmurze opartego na HSM), gdy to rozwiązanie wejdzie w życie.

Konfiguracja certyfikatu podpisującego i rotacja poświadczeń po wycieku to zadania operacyjne wykraczające poza tę stronę.