Dodatek G - Jak powstaje Rust i „Nightly Rust”
Ten dodatek opisuje, jak powstaje Rust i jak to wpływa na Ciebie jako dewelopera Rust.
Stabilność bez stagnacji
Jako język, Rust bardzo dba o stabilność Twojego kodu. Chcemy, aby Rust był solidnym fundamentem, na którym możesz budować, a gdyby rzeczy ciągle się zmieniały, byłoby to niemożliwe. Jednocześnie, jeśli nie będziemy mogli eksperymentować z nowymi funkcjami, możemy nie odkryć ważnych wad aż do momentu ich wydania, kiedy to nie będziemy już w stanie nic zmienić.
Naszym rozwiązaniem tego problemu jest to, co nazywamy „stabilnością bez stagnacji”, a nasza przewodnia zasada brzmi: nigdy nie powinieneś obawiać się aktualizacji do nowej wersji stabilnego Rusta. Każda aktualizacja powinna być bezbolesna, ale także przynosić nowe funkcje, mniej błędów i szybszy czas kompilacji.
Ciuch, ciuch! Kanały wydań i jazda pociągami
Rozwój Rusta odbywa się według rozkładu jazdy pociągów. Oznacza to, że cały rozwój odbywa się w głównej gałęzi repozytorium Rusta. Wydania są zgodne z modelem pociągu wydań oprogramowania, który był używany przez Cisco IOS i inne projekty. Istnieją trzy kanały wydań Rusta:
- Nightly
- Beta
- Stabilny
Większość deweloperów Rusta używa głównie kanału stabilnego, ale ci, którzy chcą wypróbować eksperymentalne nowe funkcje, mogą używać nightly lub beta.
Oto przykład, jak działa proces rozwoju i wydawania: załóżmy, że zespół Rusta pracuje nad wydaniem Rust 1.5. To wydanie miało miejsce w grudniu 2015 roku, ale dostarczy nam realistycznych numerów wersji. Do Rusta dodawana jest nowa funkcja: nowy commit ląduje w głównej gałęzi. Każdej nocy tworzona jest nowa wersja nightly Rusta. Każdy dzień jest dniem wydania, a te wydania są tworzone automatycznie przez naszą infrastrukturę wydawniczą. Tak więc z biegiem czasu nasze wydania wyglądają tak, raz na noc:
nightly: * - - * - - *
Co sześć tygodni nadchodzi czas na przygotowanie nowego wydania! Gałąź beta repozytorium Rusta rozgałęzia się od głównej gałęzi używanej przez nightly. Teraz istnieją dwa wydania:
nightly: * - - * - - *
|
beta: *
Większość użytkowników Rusta nie używa aktywnie wydań beta, ale testuje je w swoich systemach CI, aby pomóc Rustowi odkryć możliwe regresje. W międzyczasie, każdej nocy nadal pojawia się wydanie nightly:
nightly: * - - * - - * - - * - - *
|
beta: *
Powiedzmy, że znaleziono regresję. Dobrze, że mieliśmy trochę czasu na przetestowanie wydania beta, zanim regresja wkradła się do stabilnego wydania! Poprawka jest stosowana do głównej gałęzi, tak aby nightly zostało naprawione, a następnie poprawka jest przenoszona do gałęzi beta, i tworzone jest nowe wydanie beta:
nightly: * - - * - - * - - * - - * - - *
|
beta: * - - - - - - - - *
Sześć tygodni po stworzeniu pierwszej bety, nadszedł czas na stabilne wydanie! Gałąź stable jest tworzona z gałęzi beta:
nightly: * - - * - - * - - * - - * - - * - * - *
|
beta: * - - - - - - - - *
|
stable: *
Hura! Rust 1.5 jest gotowy! Zapomnieliśmy jednak o jednej rzeczy: ponieważ minęło sześć tygodni, potrzebujemy również nowej bety następnej wersji Rusta, 1.6. Tak więc po tym, jak stable rozgałęzia się od beta, następna wersja beta ponownie rozgałęzia się od nightly:
nightly: * - - * - - * - - * - - * - - * - * - *
| |
beta: * - - - - - - - - * *
|
stable: *
Nazywa się to „modelem pociągu”, ponieważ co sześć tygodni wydanie „opuszcza stację”, ale nadal musi odbyć podróż przez kanał beta, zanim dotrze jako stabilne wydanie.
Rust wydaje się co sześć tygodni, jak w zegarku. Jeśli znasz datę jednego wydania Rusta, możesz poznać datę następnego: to sześć tygodni później. Miłym aspektem harmonogramu wydań co sześć tygodni jest to, że następny pociąg nadjedzie wkrótce. Jeśli jakaś funkcja przypadkowo ominie konkretne wydanie, nie ma powodu do obaw: kolejne pojawi się w krótkim czasie! Pomaga to zmniejszyć presję na dodawanie niedopracowanych funkcji tuż przed terminem wydania.
Dzięki temu procesowi zawsze możesz sprawdzić następną kompilację Rusta i samodzielnie zweryfikować, że łatwo jest ją zaktualizować: jeśli wydanie beta nie działa zgodnie z oczekiwaniami, możesz zgłosić to zespołowi i uzyskać poprawkę przed wydaniem kolejnej stabilnej wersji! Awarie w wydaniu beta są stosunkowo rzadkie, ale rustc to nadal oprogramowanie, i błędy istnieją.
Czas wsparcia
Projekt Rust wspiera najnowszą stabilną wersję. Gdy nowa stabilna wersja zostanie wydana, stara wersja osiąga koniec swojego życia (EOL). Oznacza to, że każda wersja jest wspierana przez sześć tygodni.
Funkcje niestabilne
W tym modelu wydań jest jeszcze jedna kwestia: funkcje niestabilne. Rust używa techniki zwanej „flagami funkcji” do określania, które funkcje są włączone w danym wydaniu. Jeśli nowa funkcja jest w trakcie aktywnego rozwoju, trafia ona do głównej gałęzi, a zatem do nightly, ale za flagą funkcji. Jeśli jako użytkownik chcesz wypróbować funkcję będącą w fazie rozwoju, możesz to zrobić, ale musisz używać wydania nightly Rusta i opatrzyć swój kod źródłowy odpowiednią flagą, aby ją włączyć.
Jeśli używasz wydania beta lub stabilnego Rusta, nie możesz używać żadnych flag funkcji. To jest klucz, który pozwala nam praktycznie korzystać z nowych funkcji, zanim ogłosimy je na zawsze stabilnymi. Ci, którzy chcą wypróbować najnowsze rozwiązania, mogą to zrobić, a ci, którzy chcą solidnego doświadczenia, mogą pozostać przy stabilnej wersji i wiedzieć, że ich kod nie zostanie zepsuty. Stabilność bez stagnacji.
Ta książka zawiera informacje wyłącznie o stabilnych funkcjach, ponieważ funkcje w trakcie rozwoju wciąż się zmieniają, i z pewnością będą się różnić między czasem, gdy ta książka została napisana, a momentem, gdy zostaną włączone w stabilnych kompilacjach. Dokumentację funkcji dostępnych tylko w nightly można znaleźć online.
Rustup i rola Rust Nightly
Rustup ułatwia przełączanie się między różnymi kanałami wydań Rusta, globalnie lub na zasadzie projektu. Domyślnie będziesz mieć zainstalowanego stabilnego Rusta. Aby zainstalować nightly, na przykład:
$ rustup toolchain install nightly
Możesz również zobaczyć wszystkie łańcuchy narzędzi (wydania Rusta i powiązane komponenty), które zainstalowałeś za pomocą rustup. Oto przykład na komputerze z systemem Windows jednego z autorów:
> rustup toolchain list
stable-x86_64-pc-windows-msvc (default)
beta-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc
Jak widać, stabilny łańcuch narzędzi jest domyślny. Większość użytkowników Rusta używa stabilnej wersji przez większość czasu. Możesz chcieć używać stabilnej wersji przez większość czasu, ale używać nightly w konkretnym projekcie, ponieważ zależy Ci na najnowszej funkcji. Aby to zrobić, możesz użyć rustup override w katalogu tego projektu, aby ustawić łańcuch narzędzi nightly jako ten, którego rustup powinien używać, gdy znajdujesz się w tym katalogu:
$ cd ~/projects/needs-nightly
$ rustup override set nightly
Teraz, za każdym razem, gdy wywołasz rustc lub cargo w katalogu ~/projects/needs-nightly, rustup upewni się, że używasz Rusta nightly, zamiast domyślnego stabilnego Rusta. Jest to przydatne, gdy masz wiele projektów Rust!
Proces RFC i zespoły
Jak więc dowiedzieć się o tych nowych funkcjach? Model rozwoju Rusta opiera się na procesie Request For Comments (RFC). Jeśli chcesz wprowadzić ulepszenie w Rust, możesz napisać propozycję, zwaną RFC.
Każdy może pisać RFC, aby ulepszyć Rusta, a propozycje są recenzowane i dyskutowane przez zespół Rusta, który składa się z wielu podzespołów tematycznych. Pełną listę zespołów można znaleźć na stronie Rusta, która obejmuje zespoły dla każdego obszaru projektu: projektowanie języka, implementacja kompilatora, infrastruktura, dokumentacja i wiele innych. Odpowiedni zespół czyta propozycję i komentarze, pisze własne komentarze, a ostatecznie osiąga się konsensus w sprawie zaakceptowania lub odrzucenia funkcji.
Jeśli funkcja zostanie zaakceptowana, otwierane jest zgłoszenie w repozytorium Rusta i ktoś może ją zaimplementować. Osoba, która ją zaimplementuje, bardzo dobrze może nie być osobą, która pierwotnie zaproponowała tę funkcję! Kiedy implementacja jest gotowa, trafia do głównej gałęzi za bramą funkcji, tak jak omówiliśmy w sekcji „Funkcje niestabilne”.
Po pewnym czasie, gdy deweloperzy Rusta korzystający z wydań nightly będą mogli wypróbować nową funkcję, członkowie zespołu przedyskutują tę funkcję, jak sprawdziła się w nightly, i zdecydują, czy powinna trafić do stabilnego Rusta, czy nie. Jeśli decyzja zostanie podjęta o kontynuowaniu, brama funkcji zostaje usunięta, a funkcja jest teraz uważana za stabilną! Trafia ona pociągami do nowego stabilnego wydania Rusta.