Dla deweloperów

Plik klasy (.CLS)

Wygląd dokumentów tworzonych z użyciem szablonu zdefiniowany jest w pliku klasy eiti-thesis.cls. Pliki zawierające treść właściwego dokumentu (.tex) formatowane są zgodnie z plikiem klasy. Zawartość pliku .cls traktowana jest jako publiczne API niniejszego szablonu (w rozumieniu inżynierii oprogramowania) i podlega wersjonowaniu zgodnie z odpowiednimi zaleceniami.

Makefile - kompilowanie szablonu

Budowanie szablonu odbywa się z linii komend za pomocą Makefile. Dostępne są następujące komendy:

make pdf, make lua, make xetex

Tworzy PDF-a z użyciem kompilatorów, odpowiednio: pdfTeX, LuaTex oraz XeTeX. Wygenerowany plik PDF jest umieszczany w katalogu pdfs, wraz z nazwą kompilatora.

make all

Tworzy wszystkie 3 wymienione wyżej PDF-y i umieszcza je w folderze pdfs.

make clean

Czyści katalog z plików pośrednich kompilacji (katalog build, wyłączony z kontroli wersji); usuwa również pliki pośrednie istniejące w katalogu głównym oraz PDF-y, istniejące zarówno w katalogu głównym jak i w folderze pdfs.

make release version=X.Y.Z

Tworzy (w folderze releases) archiwum ZIP zawierające wersję szablonu gotową do kompilacji na lokalnej maszynie. Wytyczne dot. numerów wersji zostały opisane w rozdziale Wersjonowanie.

Branch protection, CI, Quality Assurance

Branch master ma status protected: każdy nowy kod musi być najpierw zacommitowany do osobnego brancha, a następnie przejść przez wszystkie testy (Continuous Integration) i zostać zatwierdzony przez administratora (tzn. przeze mnie) przed jego zmerge'owaniem do głównego brancha.

Testy automatycznie z użyciem GitHub Actions. Po każdym commicie, tworzony jest osobny build dla trzech kompilatorów: pdfTeX, LuaTeX i XeTeX. Build jest traktowany jako zaliczony, jeżeli szablon zbuduje się poprawnie na każdym z trzech kompilatorów.

Wersjonowanie

Każda kolejna wersja szablonu musi być oznaczona numerem wersji w formacie Major.Minor.Patch. Schemat wersjonowania jest zgodny z (nieco uproszczonymi) zasadami Semantic Versioning:

• Wersja Major ulega zmianie po wprowadzeniu zmian łamiących wsteczną kompatybilność (backward incompatible changes), tj. zmian, które:
  • uniemożliwiają kompilację kodu z użyciem pliku klasy z poprzedniej wersji;
  • znacząco zmieniają wygląd dokumentu (co może wymagać ponownych rozmów z Instytutami);
• Wersja Minor ulega zmianie przy wprowadzaniu nowych funkcji LaTeX-a, np. nowego znacznika, które nie powodują złamania wstecznej kompatybilności;
• Wersja Patch ulega zmianie w pozostałych przypadkach (np. bugfixy, komentarze, dokumentacja).