Release cycle pl PL

Cykl wydań

ASF używa powszechnej wersji C# z 4 numerami, napisanej jako A.B.C.D. Podana wersja jest zawsze zamrożona, wskazując na stały kod źródłowy, z którego została zbudowana (razem z wydaniem). Nie zamierzamy usuwać żadnej poprzednio opublikowanej wersji, dopóki nasz dostawca usług hostingowych (GitHub) pozostanie w porządku, zachowując je na czas nieokreślony, aby można było bezpiecznie powrócić do któregokolwiek z nich bez konieczności samodzielnego kopiowania.

In general in terms of ASF versioning, we're doing our best to follow semver versioning of MAJOR.MINOR.PATCH on the 3 least significant numbers - B.C.D. Te trzy numery są bezpośrednio związane z kodem ASF. The most significant A number indicates changes with a scope that goes beyond ASF codebase itself, usually directly affecting the foundation of the program.

ASF jako projekt ma na celu uzyskanie mniej więcej jednej wersji na miesiąc, oznaczony liczbą C. Aby umożliwić takie wydanie, mamy mniejsze prewydania przeznaczone dla zaawansowanych użytkowników, które służą jako mniejsze etapy zmian, które są uwalniane zgodnie z potrzebami, gdy od czasu ostatniego wydania nastąpi wystarczająco dużo zmian, aby skupić się na tych zmianach. Ostatecznie, kiedy ostateczne uwolnienie wstępne zostanie określone jako stabilne i wystarczająco dojrzałe, przy braku znanych krytycznych regresji, które należy skorygować w porównaniu z poprzednim stabilnym uwolnieniem, zostanie awansowana do nowej stabilnej wersji, jednocześnie otwierając nowy cykl miesięczny dla następnego.

Podczas gdy robimy wszystko, co w naszej mocy, aby nawet nasze wstępne wydania były stosunkowo stabilne, należy zauważyć, że przed wydaniem powinien być starannie oceniany podczas działania w jakimkolwiek środowisku produkcyjnym. Wstępne wydania mogą mieć krytyczne błędy i w inny sposób uszkodzone funkcje, Właśnie dlatego udostępniamy je na początku - abyśmy mogli uniknąć tego bałaganu w naszych stabilnych wersjach i oferować niezawodne oprogramowanie. Jeśli pacjent nie jest skłonny zaakceptować zwiększonego ryzyka związanego z używaniem potencjalnie niestabilnego oprogramowania, unikaj korzystania z naszych wersji wstępnych i trzymaj się naszego najnowszego stabilnego zamiast tego, które jest bardziej odpowiednie dla większości użytkowników.

Zależnie od ilości zmian w cyklu, zwykle będzie pojedynczy zrzut wersji C (z poprzedniej stabilności), oraz D uderzenia na każde wstępne wydanie w sposób zgodny z potrzebami. However, when introducing changes with far bigger scope, especially breaking changes, the cycle might start from (or switch in the middle to) B or even A bump - such switch indicates that current release cycle has a potential to be more unstable than usual, and should be tested carefully. Pamiętaj, że zmiany semestru, które wprowadzamy, odnoszą się tylko do poprzednio wydanej stabilnej wersji, nie śledzimy wersji we wszystkich wersjach wstępnych w samym cyklu, co oznacza, że wersja 1. .1.2 może mieć nową funkcję, która 1.0.1. nie posiadał, dopóki poprzednio oznaczone stabilne wydanie jest z rodziny 1.0.0.X. Podobnie mogą wystąpić poważne zmiany przełomowe, nawet w przypadku dwóch wstępnych uwolnień z tego samego cyklu, co jest szczególnie prawdziwe, gdy wciąż decydujemy o ostatecznym kształcie nowo wprowadzonej funkcjonalności.

Zrzut wersji	Semver	Przykład zmian
A		Główne zmiany czasu pracy .NET, zmiany fundamentów, przełomowe zmiany, które wykraczają poza kodową bazę ASF, rzeczy, które mogą zjeść kota
B	Poważne	Mniejsze zmiany czasu pracy .NET, zmiany w kodzie ASF, główne edycje kodu, które wykraczają poza drobną klasyfikację
C	Małe	Nowe comiesięczne cykle, zazwyczaj wprowadzające nowe funkcje, polecenia, właściwości konfiguracji lub inne zmiany, które nie naruszają istniejących konfiguracji.
D	Łatka	nowe wstępne uwolnienia, które stanowią część istniejącego cyklu (znacząca liczba), krytyczne poprawki błędów do istniejących stabilnych wersji, które nie wprowadzają żadnych zmian kodu poza niezbędnymi

Należy pamiętać, że nowo wprowadzone funkcje i zmiany mogą być nieudokumentowane (np. na wiki), do pewnego czasu później, ponieważ dokumentacja jest zazwyczaj napisana po przygotowaniu ostatecznego kodu danej funkcji (aby zaoszczędzić nam dokumentację przepisywania czasu za każdym razem, gdy zdecydujemy się na zmianę funkcji, nad którą obecnie pracujemy). Ze względu na fakt, że wstępne wydania mogą zawierać kod w toku, który nie ma jeszcze ostatecznego formularza, dokumentacja może dotrzeć do późniejszego etapu rozwoju. To samo dotyczy ogólnego dziennika zmian, które mogą być niedostępne dla danej wersji wstępnej do jakiegoś czasu później. Dlatego, jeśli zdecydujesz się użyć wersji wstępnych, bądź przygotowany do oglądania wewnątrz ASF commits od czasu do czasu. Oczywiście, brak dokumentacji stosuje tylko do wstępnych wydań - każda stabilna wersja musi zawsze mieć kompletny dziennik zmian i dokumentację wiki w momencie wydania.

Dokładny dziennik zmian, który porównuje jedną wersję z inną, jest zawsze dostępny na GitHub - poprzez commity i zmiany kodu. W wydaniu zwykle dokumentujemy tylko zmiany, które uważamy za ważne między ostatnim wydaniem stabilnym a bieżącym. Taki krótki dziennik zmian nigdy nie jest kompletny, więc jeśli chciałbyś zobaczyć każdą zmianę, która nastąpiła pomiędzy jedną wersją a drugą (jak nasze zależności ulepszyły) - użyj GitHub porównanie dla tego.

Projekt ASF jest wspierany przez nasz proces ciągłej integracji. Każda kompilacja powinna być odtwarzalna, więc nie powinno być problemem, aby chwycić źródło (zawarte w wydaniu) danej wersji i skompilować się otrzymując taki sam wynik jak ten dostępny za pośrednictwem naszych wstępnie skompilowanych plików binarnych. Zwykle unikamy kompilacji samych się, dopóki systemy będą działać, uwolnione pliki binarne pochodzą bezpośrednio z naszego procesu CI.