Nowości z php.internals – proces wydawniczy

Felipe Pena, jeden z najaktywniejszych deweloperów PHP wraz z całym szeregiem innych prominentnych uczestników projektu ogłosił RFC – propozycje zmian w cyklu wydawniczym interpretera. Jak dotąd, wszelkie nowe wydania powstawały spontanicznie. Po prostu po zakumulowaniu się jakiejś masy krytycznej nowych rzeczy w repozytorium, ktoś wyskakiwał jak to “Filip z konopi indyjskich” i mówił, że robimy nowego releasa. Skutkowało to tym, że nikt nigdy nie wiedział, kiedy wyjdzie nowa wersja interpretera. Przez to też między innymi tak wolno nowe wersje dostają się na hostingi, czy do stabilnych wydań Debiana. Nie ma też żadnej ścieżki, dzięki której, można by informować o zmianach we wstecznej kompatybilności, przez co bardzo wiele czasu zajmuje usunięcie jakiś śmieci z poprzednich wersji (magic_quotes etc). RFC proponuje:

  • cykliczny proces wydawniczy
  • demokratyczny proces podejmowania decyzji, wszelkie zmiany wprowadzane będą poprzez RFC, a decyzja podejmowana poprzez anonimowe głosowanie
  • typ zmian, jakie mogą być wprowadzane w poszczególnych rodzajach wydań
  • demokratyczny proces wybierania menedżerów wydań dla danego wydania
  • efektywniejsze użycie bugs.php.net do śledzenia zmian i błędów
  • skrócony czas między wydaniami poprawiającymi błędy
  • skrócony czas wprowadzania nowych rzeczy do języka
  • brak zrywania kompatybilności wstecznej dla wydań poprawiających błędy
  • wydania podglądowe, mające na celu przedstawienie jakiejś funkcjonalności szerszej publice

Więcej szczegółów znajdziecie w RFC, natomiast chciałem jeszcze pokrótce omówić rodzaje wydań.

  • Wydania serwisowe – zmiana numerów wersji wg porządku x.y.z -> x.y.z+1 – tylko poprawki błędów, konieczność zachowania kompatybilności wstecznej, nie można usuwać rozszerzeń
  • Małe wydania – x.y.z -> x.y+1.z – poprawki błędów, nowe cechy języka, można usuwać rozszerzenia, konieczność zachowania kompatybilności wstecznej
  • Duże wydania – x.y.z -> x+1,y,z – wszystko to samo co w przypadku małych wydań z tą różnicą, że można zerwać kompatybilność wsteczną

Długość cyklu wydawniczego dla małego lub dużego wydania:

  • 1 rok tworzenia (np. robimy wersję 5.4.0)
  • 2 lata poprawek błedów (wersje 5.4.x)
  • 1 rok samych błędów bezpieczeństwa (wersje 5.4.x)

Osobiście uważam, że ta propozycja to świetny pomysł. Na pewno przyśpieszy wydawanie nowych wersji, które dzięki przewidywalności daty pojawienia się będą szybciej adoptowane przez hostingi.

  1. batman says:

    Dobrze, że PHP będzie wydawany regularnie. Jednak ostrożnie podchodziłbym do sztywnych terminów, ponieważ robienie czegoś w pośpiechu może tylko pogorszyć sprawę. Dla mnie w zupełności wystarczy, że co około rok będzie pojawiała się nowa wersja języka wprowadzająca (niekoniecznie rewolucyjne) usprawnienia.

  2. No jeszcze nic nie wiadomo, dopiero ziarno zostało zasiane. Pewnie niedługo przetoczy się dość długa dyskusja i wtedy się okaże, czy propozycja została zaakceptowana. Co do sztywnych terminów to myślę, że wystarczyła by zasada, że jak coś nie jest gotowe, to przechodzi do następnego wydania, w ten sposób łatwo uniknąć robienia czegoś w pośpiechu.

  3. Systematyka w każdym przypadku zrobi więcej dobrego niż złego, także jestem za. Ciekawe tylko, czy developerzy PHP będą w stanie “przestawić się” na taki nowy tryb pracy.

  4. Sebastian Tarach says:

    Jestem tego samego zdania co batman. Oby nie strugali interpretera w pośpiechu, bo im wyjdzie Pinokio i w wynikach skryptów będą przekłamania.

    Zastanawia mnie tylko ten aspekt demokratyczny. Kto będzie mógł głosować i ile to będzie osób.

  1. There are no trackbacks for this post yet.

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.