# Wersjonowanie

W Eximee każdy **element aplikacji** – np. formularz, proces, skrypt czy treść – posiada własną historię wersji, zarządzaną bezpośrednio w repozytorium. Mechanizm wersjonowania umożliwia bezpieczne wprowadzanie zmian, śledzenie modyfikacji oraz łatwe przywracanie wcześniejszych wersji w razie potrzeby.

### **Wersje główne i podrzędne**

System wersjonowania rozróżnia dwa poziomy wersji:

* **Wersje główne (major)** – oznaczane kolejnymi liczbami całkowitymi: `1`, `2`, `3`, itd.\
  Służą do oznaczania zmian, które mają wpływ na działanie aplikacji lub jej strukturę (np. zmiana schematu danych, logiki procesu, powiązań między komponentami).
* **Wersje podrzędne (minor)** – oznaczane jako liczba zmiennoprzecinkowa względem wersji głównej: `1.1`, `1.2`, `1.3`, itd.\
  Używane są przy wprowadzaniu mniejszych zmian, które nie wpływają na interfejs aplikacji ani nie wymagają dostosowania zależnych komponentów (np. zmiana tekstu, poprawki układu, kosmetyczne modyfikacje).

{% hint style="info" %}
**Pierwsza wersja każdego elementu aplikacji to `1.0`.**
{% endhint %}

Przy zapisywaniu zmian użytkownik decyduje, czy tworzy **nową wersję główną** czy **podrzędną**. Wersjonowanie odbywa się ręcznie – system nie narzuca automatycznego podbicia numeru wersji.

### **Wersja robocza (szkic)**

W momencie edycji elementu aplikacji automatycznie tworzona jest jego **wersja robocza (draft)**. Wersja robocza to tymczasowa kopia edytowanego elementu, która nie wpływa jeszcze na działanie aplikacji i nie jest widoczna dla innych użytkowników.

Kluczowe zasady pracy z wersją roboczą:

* Dla danej **gałęzi wersji głównej** (`np. 3.*`) może istnieć tylko **jedna wersja robocza** w danym czasie.
* Edytowanie wersji roboczej **blokuje gałąź**, co oznacza, że inni użytkownicy nie mogą jednocześnie wprowadzać zmian na tej samej wersji głównej.
* Blokada jest zdejmowana automatycznie, gdy użytkownik:
  * zapisze wersję roboczą jako nową wersję `major` lub `minor`,
  * albo porzuci wersję roboczą bez zapisu.

Wersja robocza pozwala na bezpieczne eksperymentowanie ze zmianami – dopiero zapis (promocja) wersji do repozytorium sprawia, że staje się ona dostępna w historii i może być wykorzystana w aplikacjach.

### **Historia wersji**

Każdy element aplikacji posiada dostępną z poziomu interfejsu zakładkę **Historia wersji**, w której widoczne są:

* wszystkie zatwierdzone wersje (`1.0`, `1.1`, `2.0` itd.),
* opisy zmian (jeśli zostały dodane przy zapisie),
* autor i data modyfikacji,
* dostęp do porównania zawartości między wersjami,
* możliwość przywrócenia wybranej wersji jako nowej roboczej.

Dzięki temu łatwo można prześledzić zmiany w czasie i zachować pełną kontrolę nad rozwojem każdego elementu aplikacji.

<figure><img src="https://1082717226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2FvwL0PUK8Om9flBIeB5Wk%2Fimage.png?alt=media&#x26;token=196271d0-8289-4580-833f-71b9a71669f8" alt=""><figcaption><p align="center"><em><strong>Ilustracja 1.</strong> Widok "Historii wersji"</em></p></figcaption></figure>

Na ilustracji 1 widzimy historię wersji szablonu wniosku, który posiada wiele wersji głównych. W wersji głównej 11.\* ma 5 wersji podrzędnych (od 11.0-11.4).

### Odcinanie gałęzi głównej, w tym produkcyjnej

Odcinanie gałęzi głównej jest szczególnie zalecane przed rozpoczęciem większych zmian — takich jak przebudowa procesów, modyfikacja struktury danych czy rozwój nowych funkcjonalności — które mogłyby wpłynąć na stabilność działającej aplikacji.

Mechanizm odcinania gałęzi głównej stosowany jest do rozdzielenia stabilnej wersji (np. produkcyjnej) aplikacji lub wniosku od prac nad nowymi fukcjonalnościami. Odcinanie gałęzi polega na utworzeniu nowej wersji głównej (major), która stanowi niezależną przestrzeń do dalszego rozwoju.

<figure><img src="https://1082717226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2Fgit-blob-3f6b59d43870cf0b3c2c88d74cbe6a4da73cd4a1%2Fnowa-wersja-g%C5%82%C3%B3wna-tworzenie.png?alt=media" alt=""><figcaption><p align="center"><em><strong>Ilustracja 2.</strong> Rozdzielenie wersji produkcyjnej i rozwojowej</em></p></figcaption></figure>

W praktyce oznacza to, że wersja 1.\* (np. 1.12) może nadal funkcjonować na produkcji, podczas gdy zespół równolegle pracuje nad wersją 2.\*, rozwijając ją niezależnie aż do momentu jej gotowości do wdrożenia. Takie podejście pozwala jednocześnie utrzymywać stabilną wersję aplikacji oraz rozwijać kolejną, minimalizując ryzyko błędów i konfliktów między zmianami. W razie potrzeby możliwe jest również wprowadzanie poprawek w gałęzi produkcyjnej bez wpływu na nową, rozwijaną wersję.

<figure><img src="https://1082717226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2Fgit-blob-455436da6166358586c31c400112371307d324b4%2Frownolegle-wersje-glowne.png?alt=media" alt=""><figcaption><p align="center"><em><strong>Ilustracja 3.</strong> Równoległy rozwój wersji 2.0 przy utrzymaniu wersji 1.*</em></p></figcaption></figure>

Odcinanie gałęzi produkcyjnej jest szczególnie zalecane przed rozpoczęciem większych zmian — takich jak przebudowa procesów, modyfikacja struktury danych czy rozwój nowych funkcjonalności — które mogłyby wpłynąć na stabilność działającej aplikacji.