eu07/maszyna
17
0
Fork 0
mirror of https://github.com/MaSzyna-EU07/maszyna.git synced 2026-10-17 00:29:19 +02:00
Code Issues 150 Wiki Activity

Propozycja nowego systemu tworzenia i publikowania exe na Steam #540

New Issue
Open
opened 2026-09-30 16:22:50 +02:00 by jakubg1 · 0 comments
jakubg1 commented 2026-09-30 16:22:50 +02:00
Owner
Copy Link

Zmotywowany tragicznym stanem exe na weekly/beta i obwinianiem wszystkich za wszystko, zdecydowałem się zaprojektować system, który mam nadzieję ograniczy nieporozumienia i jasno wyizoluje gdzie testujemy exe.

Do rzeczy. Oto schemat proponowanego nowego cyklu "wydawniczego" exe.

image.png

Na repozytorium exe kluczową rolę będą odgrywać dwa branche:

  • Staging to swego rodzaju "inkubator", do którego mergowane są wszystkie pull requesty tak, aby zachować najlepszą jakość kodu. Exe z tego brancha będzie lecieć na wydania Beta na Steam.
  • Master to główny stan kodu, do którego mergowany będzie cały staging w momencie kiedy kod na nim będzie na tyle dobrej jakości, że nie będzie widać problemów po testach. Exe z tego brancha będzie lecieć na wydania Weekly oraz na pełne wydania symulatora.

Sposób działania jest prosty. Każdy cykl zaczyna się od zmergowania dowolnej liczby uprzednio wstępnie przetestowanych przez nas pull requestów do brancha staging, zakładając że branch staging do tego momentu jest równy branchowi master.
Po wrzuceniu różnej maści zmian do inkubatora następuje kompilacja exe i wydanie nowej bety na Steam z tym nowym exe. Wydanie powinno być ogłoszone wraz z listą zmian, aby znaleźć jak najwięcej osób chętnych do testowania oraz żeby testy były możliwie precyzyjne. Oczywiście ogólnikowe testy typu przejechanie scenariusza są równie ważne.
Jeżeli pojawią się błędy, których nie ma w paczce całościowej, a pojawiły się na becie, to jest to regresja i powinny zostać naprawione. Czas na naprawę błędów może być dowolny, ale dopóki wszystkie takie błędy nie zostaną naprawione, niemożliwe będzie przejście do kolejnego cyklu.
Napływające PR nie mogą być mergowane, ale mogą być testowane, aby je zaaprobować bądź poprosić o zmiany. Wyjątek stanowią PR, które zawierają poprawki do tego co jest w danym momencie na staging - te powinny być mergowane stosunkowo szybko, aby łatać kod w inkubatorze.
Po stwierdzeniu, że chcemy dać nową wersję do testowania, rozpoczynamy nową iterację, w większości tą samą procedurą. Ponownie robimy kompilację, nowe wydanie bety i ogłoszenie, w którym wskazujemy listę naprawionych błędów, oraz tych jeszcze do naprawienia.
Iteracje powtarzają się do momentu, kiedy po wydaniu nie zostają zgłoszone żadne błędy, które byłyby zakwalifikowane jako regresje względem paczki całościowej/weekly. W takim wypadku po dwóch tygodniach następuje zamknięcie cyklu poprzez wrzucenie całej zawartości staging do mastera, wrzucenie nowego release na Githubie oraz pojawienie się nowego exe na weekly w momencie kiedy bot zdecyduje się wygenerować nową paczkę weekly. Nowa wersja weekly nie musi być ogłaszana, ale gracze weekly mogą stanowić drugie sito jeżeli coś prześlizgnęło się przez betę, tak aby do paczki całościowej trafiło jak najbardziej stabilne exe.

Bardzo gorąco proszę się o wypowiedź w szczególności deweloperów exe @Hirek , @MichauSto , @danniel , @daniu , @DzordZ . :)

Zmotywowany tragicznym stanem exe na weekly/beta i obwinianiem wszystkich za wszystko, zdecydowałem się zaprojektować system, który mam nadzieję ograniczy nieporozumienia i jasno wyizoluje gdzie testujemy exe. Do rzeczy. Oto schemat proponowanego nowego cyklu "wydawniczego" exe. ![image.png](/attachments/96e2fc39-cbf9-41b9-b48f-5f03a475108d) Na repozytorium exe kluczową rolę będą odgrywać dwa branche: - Staging to swego rodzaju "inkubator", do którego mergowane są wszystkie pull requesty tak, aby zachować najlepszą jakość kodu. Exe z tego brancha będzie lecieć na wydania Beta na Steam. - Master to główny stan kodu, do którego mergowany będzie cały staging w momencie kiedy kod na nim będzie na tyle dobrej jakości, że nie będzie widać problemów po testach. Exe z tego brancha będzie lecieć na wydania Weekly oraz na pełne wydania symulatora. Sposób działania jest prosty. Każdy cykl zaczyna się od zmergowania dowolnej liczby uprzednio wstępnie przetestowanych przez nas pull requestów do brancha staging, zakładając że branch staging do tego momentu jest równy branchowi master. Po wrzuceniu różnej maści zmian do inkubatora następuje kompilacja exe i wydanie nowej bety na Steam z tym nowym exe. Wydanie powinno być ogłoszone wraz z listą zmian, aby znaleźć jak najwięcej osób chętnych do testowania oraz żeby testy były możliwie precyzyjne. Oczywiście ogólnikowe testy typu przejechanie scenariusza są równie ważne. Jeżeli pojawią się błędy, których nie ma w paczce całościowej, a pojawiły się na becie, to jest to regresja i powinny zostać naprawione. Czas na naprawę błędów może być dowolny, ale dopóki wszystkie takie błędy nie zostaną naprawione, niemożliwe będzie przejście do kolejnego cyklu. Napływające PR nie mogą być mergowane, ale mogą być testowane, aby je zaaprobować bądź poprosić o zmiany. Wyjątek stanowią PR, które zawierają poprawki do tego co jest w danym momencie na staging - te powinny być mergowane stosunkowo szybko, aby łatać kod w inkubatorze. Po stwierdzeniu, że chcemy dać nową wersję do testowania, rozpoczynamy nową iterację, w większości tą samą procedurą. Ponownie robimy kompilację, nowe wydanie bety i ogłoszenie, w którym wskazujemy listę naprawionych błędów, oraz tych jeszcze do naprawienia. Iteracje powtarzają się do momentu, kiedy po wydaniu nie zostają zgłoszone żadne błędy, które byłyby zakwalifikowane jako regresje względem paczki całościowej/weekly. W takim wypadku po dwóch tygodniach następuje zamknięcie cyklu poprzez wrzucenie całej zawartości staging do mastera, wrzucenie nowego release na Githubie oraz pojawienie się nowego exe na weekly w momencie kiedy bot zdecyduje się wygenerować nową paczkę weekly. Nowa wersja weekly nie musi być ogłaszana, ale gracze weekly mogą stanowić drugie sito jeżeli coś prześlizgnęło się przez betę, tak aby do paczki całościowej trafiło jak najbardziej stabilne exe. Bardzo gorąco proszę się o wypowiedź w szczególności deweloperów exe @Hirek , @MichauSto , @danniel , @daniu , @DzordZ . :)
image.png
144 KiB
👍 1
jakubg1 added the www/git!importantrepo/ogólne labels 2026-09-30 16:22:50 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
!important
Do oznaczania ważnych kwestii
 błąd
Błąd w symulatorze
 cleanup
Usuwanie zawartości lub funkcjonalności, porządki
 duplikat
Ten błąd był już zgłoszony
 exe/edytor
Exe - sprawy dotyczące edytora
 exe/fizyka
Exe - fizyka jazdy lub obsługa pojazdu
 exe/renderer
Exe - sprawy dotyczące renderera
 exe/rozgrywka
Exe - dotyczące stanów symulatora, ogólnotechniczne
 feature
propozycja usprawnienia/nowości
 odrzucone
Ten wątek nie będzie prowadzony dalej
 repo/dzwieki
Dotyczy dźwięków w symulatorze
 repo/model
Dotyczy modelu pojazdu/otoczenia
 repo/ogólne
Repo - sprawy ogólne
 repo/pojazdy
Dotyczy plików pojazdów - mmd/fiz/textures.txt - innych rzeczy pojazdowych nie kwalifikujących się do modlei/dzwiekow/tekstur
 repo/python
Dotyczy skryptów pythonowych
 repo/scenariusze
Dotyczy scenariuszy
 repo/scenerie
Dotyczy scenerii
 repo/tekstury
Dotyczy tekstur
 www/forum
Dotyczy forum
 www/git
Dotyczy portalu zgłoszeń
 www/strona-glowna
Dotyczy strony głównej eu07.pl
 www/upload
Dotyczy uploadu
 www/wiki
Dotyczy wiki.eu07.pl
No Label !important repo/ogólne www/git
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
daniu danniel DieselPower DzordZ fuji8 Hirek Iwan-XXI jakubg1 Kermit Kogut macius5991 MichauSto MiloszDorsz spot57 Turbokibel x_Zielu
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: eu07/maszyna#540
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?