Przejdź do treści głównej
Wersja: Następna

Polityka wersjonowania

Nieoficjalne Tłumaczenie Beta

Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt. Znalazłeś błąd? Zgłoś problem →

Ta strona opisuje politykę wersjonowania, którą stosujemy dla pakietu react-native.

Każdą wersję React Native dokładnie testujemy, zarówno ręcznie, jak i automatycznie, aby zapewnić, że jakość nie ulegnie pogorszeniu.

Kanał stable React Native stosuje politykę wydań 0.x.y opisaną poniżej.

React Native oferuje również kanał wydań nightly, aby zachęcić do wczesnego testowania eksperymentalnych funkcji.

Ta strona opisuje nasze podejście do numeracji wersji dla react-native oraz pakietów w zakresie @react-native.

Stabilne wersje wydań​

React Native wydaje stabilne wersje w regularnych odstępach czasu.

Stosujemy schemat wersjonowania 0.x.y:

  • Zmiany łamiące kompatybilność (breaking changes) będą wydawane w nowej wersji minor, czyli zwiększamy liczbę x (np. 0.78.0 → 0.79.0).

  • Nowe funkcje i API również będą wydawane w nowej wersji minor, czyli zwiększamy liczbę x (np. 0.78.0 → 0.79.0).

  • Krytyczne poprawki błędów będą wydawane w nowej wersji patch, czyli zwiększamy liczbę y (np. 0.78.1 → 0.78.2).

Stabilne wydania są publikowane regularnie, z najnowszą wersją oznaczoną jako latest na NPM.

Seria wydań z tą samą wersją minor nazywana jest serią minor (np. 0.76.x to seria minor dla wersji 0.76.0, 0.76.1, 0.76.2 itd.).

Więcej informacji o naszym zobowiązaniu do stabilności znajdziesz na stronie wydań.

Zmiany łamiące kompatybilność​

Zmiany łamiące kompatybilność są uciążliwe dla wszystkich, dlatego staramy się minimalizować je do absolutnego minimum. Wszystkie takie zmiany w stabilnych wydaniach będą wyróżnione w:

Dla każdej zmiany łamiącej kompatybilność zobowiązujemy się wyjaśnić jej uzasadnienie, dostarczyć zastępcze API jeśli to możliwe i zminimalizować wpływ na użytkowników końcowych.

Co uznajemy za zmianę łamiącą kompatybilność?​

Dla React Native uznajemy za zmianę łamiącą kompatybilność:

  • Niekompatybilną zmianę API (tj. zmianę lub usunięcie API, przez które twój kod przestanie się kompilować/działać). Przykłady:

    • Zmiany w API JS/Java/Kotlin/Obj-c/C++ wymagające modyfikacji kodu do kompilacji.
    • Niekompatybilne wstecz zmiany w @react-native/codegen.

  • Istotną zmianę zachowania/w czasie wykonania. Przykład:

    • Drastyczna zmiana logiki układu dla właściwości (prop).

  • Istotną zmianę w doświadczeniu developerskim. Przykład:

    • Całkowite usunięcie funkcji debugowania.

  • Podwyższenie wersji głównej (major) dla dowolnej zależności pośredniej. Przykłady:

    • Aktualizacja Reacta z 18.x do 19.x
    • Podwyższenie Target SDK na Androidzie z 34 do 35.

  • Obniżenie obsługiwanych wersji platform. Przykłady:

    • Podwyższenie min. SDK na Androidzie z 21 do 23
    • Podwyższenie min. wersji iOS do 15.1.

Nie uznajemy za zmiany łamiące kompatybilność:

  • Modyfikacje API z prefiksem unstable_: Te API udostępniają funkcje eksperymentalne, a my nie jesteśmy pewni ich ostatecznego kształtu. Dzięki prefiksowi unstable_ możemy szybciej iterować i dojść do stabilnego API.

  • Zmiany w prywatnych lub wewnętrznych interfejsach API: Te interfejsy API są często oznaczone prefiksem internal_, private_ lub znajdują się w folderze/pakiecie internal/ lub private/. Choć niektóre z tych interfejsów mogą być publicznie widoczne z powodu ograniczeń narzędziowych, nie uważamy ich za część naszego publicznego API, więc zmieniamy je bez uprzedzenia.

    • Podobnie, jeśli uzyskujesz dostęp do wewnętrznych nazw właściwości jak __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED lub __reactInternalInstance$uk43rzhitjg, nie ma żadnych gwarancji. Robisz to na własne ryzyko.
    • Klasy oznaczone adnotacją @FrameworkAPI również są uważane za wewnętrzne.

  • Zmiany w narzędziowych/rozwojowych interfejsach API: Niektóre publiczne interfejsy API React Native są zarezerwowane dla integracji z frameworkami i innymi narzędziami. Na przykład, niektóre interfejsy API Metro lub React Native DevTools są przeznaczone tylko dla innych frameworków lub narzędzi. Zmiany w tych interfejsach API są omawiane bezpośrednio z dotkniętymi narzędziami i nie są uważane za zmiany łamiące kompatybilność (nie będziemy ich szeroko komunikować w wpisach na blogu dotyczących wydań).

  • Ostrzeżenia deweloperskie: Ponieważ ostrzeżenia nie wpływają na zachowanie w czasie wykonania, możemy dodawać nowe ostrzeżenia lub modyfikować istniejące w dowolnych wersjach.

Jeśli spodziewamy się, że zmiana spowoduje szerokie problemy w społeczności, zrobimy wszystko, by zapewnić stopniową ścieżkę migracji dla ekosystemu.

Cykle wycofywania​

Podczas ciągłego rozwijania i ewoluowania React Native tworzymy nowe interfejsy API i czasami musimy wycofać istniejące. Te interfejsy API przechodzą cykl wycofania.

Po wycofaniu interfejs API pozostanie dostępny również w kolejnych stabilnych wydaniach.

Na przykład: jeśli interfejs API zostanie wycofany w React Native 0.76.x, będzie nadal dostępny w 0.77.x i nie zostanie usunięty wcześniej niż w React Native 0.78.x.

Czasami decydujemy się zachować wycofany interfejs API dłużej, jeśli uważamy, że ekosystem potrzebuje więcej czasu na migrację. Dla takich interfejsów API zwykle dostarczamy ostrzeżenia pomagające użytkownikom w migracji.

Kanały wydań​

React Native opiera się na tętniącej życiem społeczności open source, która zgłasza błędy, otwiera pull requesty i przesyła RFC. Aby zachęcić do informacji zwrotnej, obsługujemy kilka kanałów wydań.

uwaga

Ta sekcja będzie najbardziej istotna dla programistów pracujących nad frameworkami, bibliotekami lub narzędziami deweloperskimi. Programiści używający React Native głównie do budowania aplikacji dla użytkowników końcowych nie muszą martwić się innymi kanałami niż latest.

latest​

latest to stabilne wydania React Native zgodne z semver. To właśnie otrzymujesz instalując React Native z npm. To kanał, którego już dziś używasz. Aplikacje dla użytkowników końcowych korzystające bezpośrednio z React Native używają tego kanału.

Regularnie publikujemy nowsze serie minorowe React Native i aktualizujemy tag latest, aby odzwierciedlał najnowszą stabilną wersję.

next​

Zanim ogłosimy nowe wydanie React Native jako stabilne, publikujemy serię kandydatów do wydania (RC), zaczynając od RC0. Te wersje to wydania przedpremierowe (zgodnie ze schematem wersjonowania 0.79.0-rc.0) oznaczone tagiem next na NPM.

Gdy następuje rozgałęzienie i na NPM i GitHubie zaczynają być publikowane RC, warto przetestować swoją bibliotekę/framework z wersją next React Native.

To zapewni, że twój projekt będzie nadal dobrze działał z nadchodzącymi wersjami React Native.

Jednak nie używaj wersji przedpremierowych/RC bezpośrednio w aplikacjach dla użytkowników końcowych, ponieważ nie są uważane za gotowe do produkcji.

nightly​

Oferujemy również kanał wydań nightly. Nightly są publikowane codziennie z gałęzi main facebook/react-native. Nightly są uważane za niestabilne wersje React Native i nie są zalecane do użytku produkcyjnego.

Wydania nightly stosują schemat wersjonowania 0.80.0-nightly-<DATE>-<SHA>, gdzie <DATE> to data wydania wersji nightly, a <SHA> to skrót SHA commita użytego do opublikowania tej wersji.

Wydania nightly są przeznaczone wyłącznie do testowania i nie gwarantujemy, że zachowanie nie zmieni się między kolejnymi wersjami nightly. Nie stosują one protokołu semver, którego używamy dla wydań z kanałów latest/next.

Dobrym pomysłem jest skonfigurowanie przepływu CI do codziennego testowania twojej biblioteki z wersją react-native@nightly, aby zapewnić jej kompatybilność z przyszłymi wydaniami.