Główny deweloper WordPressa Andrew Ozz opublikował propozycję dodania nowego typu biletu „gutenberg-merge”, który sformalizowałby swobodę, z jaką współpracownicy Gutenberga otrzymali możliwość popełnienia kodu po Feature Freeze podczas cyklu wydania.
Zazwyczaj, wszelkie nowe funkcje i ulepszenia lądujące w wydaniu są wymagane, aby były zaangażowane przed Beta 1, aby mogły być gotowe do testów. Kiedyś zdarzało się, że tickety mogły być zmieniane z „enhancement” na „task” tuż przed Beta 1, jako rzadki wyjątek dla elementów, które nie były gotowe na czas do bety i potrzebowały po prostu kilku dni więcej, aby zostać zaangażowane.
„Intencją było umożliwienie kolejnych dwóch lub trzech dni, a nie tygodnia lub dwóch” – powiedział Ozz. „Ten wyjątek zdarzał się kiedyś dość rzadko, może kilka razy w roku.
„Jednak ostatnio ten wyjątek stał się częścią standardowego przepływu pracy związanego z wydaniem. W ostatnich latach stało się powszechne, że 15 do 20 biletów na kod pochodzący z Gutenberga jest zmienianych na zadania w każdym wydaniu. Powodem, dla którego są one zmieniane, nie jest to, aby dać deweloperom kilka dni więcej na ich wykonanie. Jest to głównie po to, aby oznaczyć, że zostaną one popełnione później.”
Ozz twierdzi, że ponieważ wtyczka funkcji Gutenberg jest używana na ponad 300 000 stronie, w tym WordPress.com, i ponieważ 60% użytkowników szybko aktualizuje się do najnowszej wersji, że wszelkie funkcje i ulepszenia pochodzące z Gutenberga zostały już przetestowane.
Sekcja komentarzy do propozycji jest aktywna z różnymi opiniami. Kilku uczestników dyskusji nie zgodziło się, że to, że funkcje są w pluginie, nie oznacza, że zostały odpowiednio przetestowane pod kątem celów, które miały osiągnąć.
„Coś, co martwi mnie o tym, jak to może działać, to fakt, że obecnie poziom dokumentacji dla funkcji, które lądują w core, ma wyższy standard niż fuzje Gutenberga” – powiedział współtwórca Core, Fabian Kägy. „Kiedy zbliżamy się do bety 1 raz, zespół dokumentacji przechodzi przez wszystkie funkcje, które zostały scalone w tym cyklu, upewniając się, że istnieją notatki dev dla wszelkich zmian, które mogą mieć wpływ na użytkowników / deweloperów. Jeśli ten termin zostanie skrócony oznacza to również, że utrzymanie tego standardu może stać się trudniejsze.”
Kägy zauważył również wyzwania związane z testowaniem przez twórców wtyczek i motywów ich rozszerzeń względem rdzenia w celu zapewnienia kompatybilności z najnowszą wersją.
„Z tym zmienionym przepływem pracy rzeczywisty czas, w którym wiesz z dość dużym prawdopodobieństwem, jakie funkcje będą częścią danego wydania rdzenia, staje się krótszy, co sprawia, że trudniej jest zapewnić kompatybilność z wydaniem w czasie wydania”, powiedział Kägy.
Peter Wilson, współtwórca rdzenia, przedstawił dwie wątpliwości związane z propozycją:
- traktując Gutenberga jako specjalny przypadek, zwiększy to konflikt między tymi, którzy przede wszystkim pracują w repozytorium WordPress-Develop, a tymi, którzy przede wszystkim pracują w repozytorium Gutenberg,
- ominięcie wymagań feature freeze dla edytora jest sprzeczne z twierdzeniem, że Core to Gutenberg, a Gutenberg to Core.
Wilson powiedział, że późne scalanie funkcji Gutenberga „było źródłem konfliktu przez kilka lat”.
„Bulk merges of Gutenberg features late in the cycle have also been an issue reported from both those who work primarily in the Gutenberg repo and those who work primarily in repo WordPress-Develop”, powiedział. „Przez lata przyrostowe fuzje podczas cyklu były zalecane, ale nigdy nie zostały osiągnięte per komentarze w linkowanym poście”.
Wilson nie zgadza się również z twierdzeniem propozycji, że funkcje opracowane w repozytorium Gutenberg są lepiej testowane w wtyczce funkcji, ponieważ celem okresów Beta i RC jest przetestowanie wydania jako całości.
„Z Gutenbergiem jako wtyczką zastępującą bloki rdzeniowe wersjami wtyczki, testowanie wydania jako całości nie ma miejsca, dopóki zmiany edytora nie zostaną scalone z WordPress-Develop” – powiedział Wilson.
„Dopiero gdy Gutenberg zostanie scalony z WordPress-Develop, testy jednostkowe zaczynają działać na różnych dostawcach hostingu uruchamiających zestaw testów w różnych środowiskach”.
WordPress Core Committer Joe McGill zachęcił autorów propozycji do rozwinięcia zasad i oczekiwań, które będą stosowane do popełniania poprawek do biletów oznaczonych nowym typem biletu.
„Na przykład, czy wszystkie te commity powinny być zakończone przed RC-1, chyba że błąd zostanie odkryty w okresie RC – i tylko odkryte poprawki zostaną popełnione, czy może są inne zasady w grze?” powiedział McGill. „Osobiście nadal uważam, że powinniśmy dążyć do tego, aby kod każdej większej nowej funkcji został scalony przed kamieniem milowym Beta-1, niezależnie od tego, czy jest on testowany w pluginie Gutenberg, czy nie”.
Dyskusja trwa w komentarzach propozycji. Chociaż proponowane zmiany wpływają przede wszystkim na głównych współpracowników, commiterów i liderów wydania, wpływają również na testerów i społeczność deweloperów wtyczek i motywów WordPressa pracujących nad zapewnieniem kompatybilności przed dużym wydaniem. Ci, którzy mają opinie na temat tego, jak funkcje Gutenberg są obsługiwane podczas i po „feature freeze”, powinni wskoczyć do komentarzy propozycji.
Kategoria: Aktualności, WordPress
