Wersjonowanie EA i changelog: podbijam wersję przy każdej edycji

W skrócie: każda edycja bota podbija numer wersji, w dwóch miejscach jednocześnie, a historia zmian leży w osobnym pliku, nie w nagłówku kodu. Dzięki temu wynik testu mogę przypisać do konkretnej wersji, a na koncie od razu widzę, czy działa to, co sądzę. Przy kilkudziesięciu botach na kilku komputerach to jedyny sposób, żeby nie zgadywać.

Po co mi wersja

Wynik testu jest wiarygodny tylko razem z wersją kodu i ustawieniami. Bez tego “bot dał PF 1,7” nie znaczy nic, bo za tydzień kod będzie inny. Wersja pomaga w trzech sytuacjach: gdy porównuję test z tym, co działa na koncie, gdy szukam, od której zmiany zachowanie się popsuło, i gdy wdrażam nową wersję na wszystkie terminale z tym botem.

Dwa miejsca, jedna liczba

W pliku bota wersja pojawia się dwa razy: w dyrektywie #property version i w stałej, którą bot wypisuje w logu przy starcie. Pierwsza widoczna jest w oknie MT5, druga w dzienniku. Jeśli się rozjadą, zaczynam wątpić, które z nich mówi prawdę. Dlatego zmieniam je zawsze razem. Chroni mnie przed tym hook przy zatwierdzaniu zmian w repozytorium: gdy numery się różnią, dostaję ostrzeżenie.

Reguła brzmi: każda edycja to nowy numer. Nawet poprawka literówki w komentarzu robi z niej nową wersję, bo w przeciwnym razie szybko pojawia się “wersja 1.30, ale trochę inna”. Mniej zasad do pamiętania daje mniej wyjątków.

Historia w osobnym pliku

Kiedyś opisywałem zmiany w nagłówku pliku .mq5. Nagłówek puchł, a przy każdej edycji trzeba było przewijać setki linii komentarzy. Teraz w nagłówku zostają tylko numer wersji, data i odnośnik do pliku changelog.md leżącego w folderze bota. Obok niego jest README.md z opisem strategii i plik z zasadami dla sesji pracy. Podobnie dla biblioteki: historia każdego pliku leży w osobnym pliku obok niego.

Wpis w changelogu piszę po polsku, krótko: co się zmieniło i dlaczego. Stare nagłówki z historią przenoszę przy najbliższej edycji danego pliku, nie hurtem.

Pułapka: zmiana w bibliotece

Moje boty korzystają ze wspólnej biblioteki klas. Gdy zmieniam w niej coś, co zmienia działanie, żaden plik bota nie jest edytowany, a mimo to bot po przekompilowaniu zachowa się inaczej. Wersja bota zostałaby stara, a kod nowy. Dlatego zmiana w bibliotece, która zmienia działanie, wymusza podbicie wersji każdego bota, który z niej korzysta. W praktyce prowadzę listę botów czekających na takie podbicie i robię je w jednej turze, przed wdrożeniem, a nie przy każdej drobnej zmianie biblioteki.

Wersja a wdrożenie

Nowa wersja bota oznacza ustawienia i wykresy na każdym terminalu, który go używa: plik .ex5, plik z ustawieniami i zapisany wykres. Przed wgraniem zapisuję kopię poprzedniego stanu, a po wgraniu sprawdzam sumę kontrolną pliku i wersję w logu startu. Zmiana trafia do repozytorium jako osobny commit z krótkim opisem.

Checklista

Czy #property version i stała wersji w kodzie mają ten sam numer?
Czy każda edycja ma nowy numer, także drobna?
Czy opis zmiany leży w changelog.md, a nie w nagłówku pliku?
Czy zmiana w bibliotece pociągnęła podbicie botów, które z niej korzystają?
Czy wynik testu zapisuję razem z wersją i ustawieniami?
Czy po wdrożeniu sprawdziłem wersję w logu startu na koncie?

[DO UZUPEŁNIENIA: przypadek, w którym brak numeru wersji utrudnił szukanie przyczyny]

Powiązane

Źródła

Brak źródeł zewnętrznych - zasady z mojego repozytorium (2026).

Ostrzeżenie: artykuł ma charakter edukacyjny i nie jest poradą inwestycyjną. Wyniki z przeszłości nie gwarantują przyszłych. Handel na rynkach finansowych wiąże się z ryzykiem utraty kapitału.