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).

Pierwsza wersja każdego elementu aplikacji to 1.0.

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.

Ilustracja 1. Widok "Historii wersji"

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).