Nie tak dawno Mozilla podjęła decyzję o znacznym skróceniu cyklu wydawniczego Firefoksa. Nowe wersje od tamtej pory ukazują się co 6 tygodni i są podzielone na cztery kanały dystrybucji: nightly, aurora, beta i stable. Teraz na grupie dyskysyjnej dla deweloperów fundacji pojawił się pomysł przejścia na 5-tygodniowy cykl wydawniczy. Co Mozilla chce w ten sposób osiągnąć?

Nie ma wątpliwości co do tego, że przeglądarka internetowa Chrome znacząco odświeżyła skostniały rynek tego typu programów. Kiedy już zdawało się, że Firefox będzie sukcesywnie spychał z tronu Internet Explorera (przy minimalnym wkładzie własnym Mozilli, bo przypomnijmy sobie jak często wprowadzano zmiany do linii 3.6.x), pojawił się trzeci gracz, który dał po łapkach jednemu i drugiemu, osiągając pułap 20 proc. w zatrważająco krótkim czasie.

Jedną ze znamiennych cech Chrome’a jest dynamicznie zmieniający się numer wersji, który rośnie równie szybko co popularność przeglądarki. Nie tak dawno ogłaszano premierę „dziewiątki”, a dziś w kanale dev mamy już wydanie oznaczone liczbą 15. Trudno nazwać to zabiegiem marketingowym, bo jakoś nie wierzę, że użytkownicy będą patrzyli na przeglądarki przez pryzmat ich numerków (chyba, że ich za bardzo przeceniam). Jak się jednak okazuje Mozilla szybko podłapała ten pomysł, bo niedługo po przełomowej wersji 4 opublikowała nowy plan wydawniczy, który zakładał znaczące przyśpieszenie udostępniania nowych wydań. W zasadzie dało się to jeszcze jakoś wytłumaczyć szybszym wdrażaniem nowych funkcji oraz łataniem dziur, co miało zaowocować tym, ze Firefox zawsze cieszyłby się opinią programu nowoczesnego. Pozytywne wrażenie zrobił też sam plan i wspomniany podział na cztery kanały dystrybucji, który sprawiał wrażenie przemyślanego i dobrze zaplanowanego.

Okazuje się jednak, że nic nie jest na tyle dobre, by nie mogło być lepsze, bo na grupach dyskusyjnych Mozilli toczy się dyskusja na temat kolejnych zmian w planie wydawniczym. Otóż pojawiła się tam propozycja zmniejszenia okresu, po którym dana kompilacja by przechodziła z niższego kanału do wyższego – miałby on wynosić 5 tygodni. Co ciekawe Christian Legnitto, release manager Firefoksa, bez ogródek zapewnił, że taka zmiana na pewno nastąpi, tylko jeszcze nie teraz. Powodem mają być trudności w przystosowaniu się do obecnego tempa, które jest przyczyną problemów z odpowiednio szybkim przygotowywaniem tłumaczeń interfejsu, a także kompatybilnością rozszerzeń.

Kolejne przyśpieszenie cyklu wydawniczego na pewno nie zaowocuje tym, że deweloperzy będą pracować wydajniej i każda kolejna wersja będzie oferowała garść nowinek. Ich tempo się bowiem nie zmieni (no, może nieznacznie wskutek lepszej organizacji pracy), za to każdorazowa zmiana numerka wersji przyniesie za sobą zwyczajnie mniej zmian (tak jak i mniej czasu jest na ich wprowadzenie). Czy jest zatem sens bawić się w takie pozorowanie dynamicznego rozwoju?

Spodobał Ci się tekst? Poleć znajomym:

iStore

iStore

  • Andrzej Libiszewski

    Firefoxa z naliczaniem sekundowym muszą wymyślić oni.

  • kamil

    eee….troche mnie zatrwozyl ostatni screen – przespalem gdzies caly rok :)

  • sieciobywatel

    Wszystkie rozważania autora można o kant… kuli potłuc, bo niedawno było rozważane także zupełne odstąpienie od numerowania wersji. Co jakoś zaprzecza tezie artykułu.
    Po prostu taki tryb pracy okazuje się znacznie, znacznie wydajniejszy, a przy tempie rozwoju technologii im szybciej użytkownicy dostaną przeglądarkę, tym lepiej.
    Głównie – jak podejrzewam – chodzi o skrócenie czasu, kiedy patche dotyczące bezpieczeństwa są już dostępne w kanałach Nighthly i Aurora, a są ich pozbawieni użytkownicy bety i release. Niestety nie wszystkie takie patche da się bez problemu przeportować do wydań opartych na wcześniejszej wersji, na przykład ze wzgledu na zmiany w architekturze.
    Krótszy cykl, to też (wbrew pozorom) płynniejsza adopcja zmian, np. przez twórców rozszerzeń czy adminów w firmach. Jeżeli w każdej wersji jest mniej zmian, to łatwiej wychwycić, która z nich psuje kompatybilność.
    Oczywiście skorzystają na tym ci, którzy przestawią się również na ciągły proces. Ale przy tempie zmian w sieci, myślenie o kompatybilności raz na półtora roku po prostu jest zupełnie nieadekwatne.

    • http://manufakturka.tk Tomasz Popielarczyk

      Trudno nazwać rozważaniami pomysł porzucenia numerowania wersji. Została rzucona luźna (bez)myśl, którą od razu zbombardowała społeczność i która właściwie nie ma racji bytu, bo się zupełnie nie sprawdzi w praktyce. Dlatego nie wiem, czy się już kompletnie z tego nie wycofano.

      Niemniej jednak zgadzam się, jeśli chodzi o zalety tak uporządkowanego cyklu wydawniczego – sam uważam, że 6-tygodniowy cykl podzielony na cztery kanały dystrybucji jest bardzo dobrze przemyślany i skuteczny – co też napisałem w tekście.

      Sprawa rozchodzi się tutaj o te bezcelowe skracanie. Teraz funkcja z kanału nightly trafia do stable po 18 tygodniach, a już przy 5-tygodniowym cyklu będzie to 15 tygodni. Wolę poczekać te 14-21 dni i dostać produkt stabilny, aniżeli otrzymać go szybciej i borykać się z niewykrytymi podczas zbyt krótkich testów problemami.

    • sieciobywatel

      Nie, to nie była rzucona luźno uwaga. Ale nie chcę tego rozwijać, bo to dość długi temat.
      Jeżeli chodzi o skracanie – taki jest właśnie cel modeli typu Agile czy Lean. Krótsza iteracja to płynniejsze zmiany i szybsza informacja zwrotna – co umożliwia dalsze doskonalenie projektu.
      Oczywiście pod warunkiem, że organizacja jest na tyle elastyczna, żeby poradzić sobie z krótszą iteracją. Ale okazało się, że zmiana nie tylko nie spowodowała większych zawirowań, ale wręcz wydania przebiegają dużo płynniej (obecnie można zegarki regulować). Naturalne jest, że jeżeli coś się sprawdza, to warto kontynuowac ten trend, prawda?

    • sieciobywatel

      Wolę poczekać te 14-21 dni i dostać produkt stabilny, aniżeli otrzymać go szybciej i borykać się z niewykrytymi podczas zbyt krótkich testów problemami.
      Możesz spojrzeć sobie na statystyki crashy i ile bugów wykrywanych jest dopiero na etapie Beta lub późniejszych. Widać wyraźnie, że właśnie dzięki szybkiemu cyklowi wydawniczemu wyraźnie obie statystyki spadły. Nigdy jeszcze wydania Firefoksa nie były tak stabilne. Co więcej – moje doświadczenie wskazuje, że przed Fx4 bety były mniej stabilne, niż dzisiaj jest Aurora. Czyli wydanie bardzo testowe.
      Pewnie, że wiele osób krytykuje, ale przeważnie nie mają na poparcie żadnych konkretnych argumentów, o twardych liczbach już nie mówiąc. Fakty świadczą jednoznacznie, że krótszy cykl to szybciej rozwijający się, prostszy w rozwoju i – paradoksalnie – bardziej stabilny projekt.
      Swoją drogą, na przykładzie zmiany modelu wydań w Mozilli można napisac nie tylko ciekawy artykuł, ale poważną pracę z dziedziny zarządzania projektami informatycznymi (a może nie tylko). Sam w swojej pracy zauważyłem, że podobny model świetnie się sprawdza (o ile organizaja jest elastyczna).

  • Zbyszek Juruś

    dla mnie totalny bezsens z tymi nulerkami
    owszem, jakas ladka to sie dawalo 3.6.1 dalej 3.6.2 itd itp
    nowa wersia to powinna zmieniac cos znaczacego
    przy takiej polityce wtyczki przestaja dzialac, a moja ulubiona skorka (na ktora czekalem miedzy wersia 4.0 a 5.0 chyba kilka miesiecy) zostala odblokowana na nowe wersjie i momentami jakies krzaki sie pojawiaja..

    niech nowa wersja bedzie co rok lub dwa, a w miedzy czasie poprostu beda dodawane latki jak do tej pory

    jezeli FF bedzie dalej tak szalal to chyba przejde na chroma bo tam chociaz wtyczki dzialaja jak powiiny z nowymi wersjami..

  • http://www.Batgraf.pl Arkadiusz Karasek

    hmm i zamiast poprawiac błedy, zmieniają tylko numerki, Głupota

  • Alexy

    Generalnie Major (pierwsza cyferka) zmienia się dopiero kiedy program naprawdę się zmienił (GUI, koncepcja, zyskał mnóstwo nowości lub zmian). Minor (druga cyferka) powinno się zmieniać, kiedy do programu wprowadzane są kolejne opcje, ale nie zmieniają znacząco programu. W przypadku Firefoxa właśnie powinniśmy mieć wersję 4.2 lub lekko wyższą. Nikt mi nie wmówi, że między firefoxem 4 a 6 są kolosalne różnice. To samo Chrome. Ale już między IE8 a IE9 widać sporą różnicę (również w funkcjonalności, bo zmiany GUI to nie wszystko)

    @sieciobywatel to że numerki szybciej rosną, nie znaczy, że aplikacja działa lepiej. Przy tych wydaniach lepiej zwiększać minor, a do łatania bugów korzystać z trzeciej pozycji w wersji: release.

    • sieciobywatel

      Aha. Czyli jakby były wersje inaczej numerowane, to Firefoks byłby jeszcze lepszy. Ciekawa koncepcja.
      Jeżeli ktoś twierdzi, że model „waterfall” (projekt > implementacja > testowanie > wydanie raz na rok) zapewnia lepszą jakość oprogramowania, to albo jest laikiem, albo przeleżał pod lodem ostatnie 5-10 lat.
      NIE MA DUŻYCH WYDAŃ I NIE BĘDZIE.
      Duże wydanie oznacza, że albo termin się przesuwa, albo cześć zaplanowanych zmian nie załapuje się na to wydanie, albo załapują się nie do końca przetestowane zmiany na siłę do tego wydania są upychane.
      Obecnie w Mozilli model wydawania Firefoksa został po prostu uproszczony. Zmiany są przygotowywane w swoim tempie (przez różne zespoły zajmujące się np. silnikiem html, kompilerem JS czy UI). W momencie, kiedy uznaje się je za gotowe lub warte przetestowania, wchodzą do mozilla-central, czyli kanału Nightly. Tam developerzy moga je przetestować i wyłapać najgroźniejsze błędy.
      Co sześć tygodni zawartość mc promowana jest do kanału Aurora, gdzie zapoznać się mogą z nową wersją liska „early adopterzy” – oraz twórcy serwisów czy rozszerzeń. Ta wersja zasadniczo działa już stabilnie.
      To co było w Aurora (testowane przez 6 tygodni) promowane jest do kanału Beta, gdzie zaczynają już używać produktu miliony. Tam wykrywane są nietypowe błędy, które występują bardzo rzadko. Obecnie zwykle niewiele takich błędów już się pojawia. Wersje te są wystarczająco stabilne dla większości użytkowników, działa też znakomita większość dodatków (bo ich twórcy mieli czas na ewentualne aktualizacje podczas leżenia wersji w Aurorze).
      Po kolejnych sześciu tygodniach wersja wypuszczana jest jako stabilna.
      Żeby było jasne – sześciotygodniowy cykl wydawania, nie oznacza, że wersja była przygotowywana przez sześć tygodni. Oznacza to, że nowe funkcje/zmiany testowane były przez od 12 do 18 tygodni. Od momentu, kiedy funkcja została uznana za zakończoną.
      Jakie są zalety?
      1. developerzy nie muszą się martwić, kiedy jest następne wydanie; jeśli nie zdążą, to nowa funkcja wejdzie po prostu później – ale tylko 6 a nie 60 tygodni później.
      2. Wydania są znacznie lepiej przetestowane
      3. Twórcy rozszerzeń i serwisów mają ułatwione dostosowywanie swoich produktów do zmian – już od Aurory wiedzą co stanie się Firefoksem za 12 miesięcy. Co więcej, zmiany przychodzą regularnie i w mniejszych „paczkach”. Można ułożyć sobie regularny plan testowania produktu, ewentualne niekompatybilności łatwo umiejscowić.
      4. Użytkownicy dostają szybciej rozwijający się produkt, nowe technologie webowe znacznie szybciej trafiają do szerokiego grona odbiorców.

    • Alexy

      No ok, ale ja mówię o numerkach a Ty o cyklu wydawniczym. To że program wydawany jest częściej nie znaczy że trzeba trzaskać numerkami jak najszybciej. W takim wypadku mielibyśmy dzisiaj Gadu-Gadu 25, WinZipa 40, Operę 60 i Windowsa 100.
      Numeracja wersji oprogramowania nie składa się dla picu z czterech liczb, po to aby ostatnie 3 nie miały żadnego znaczenia. A teraz można rzec, że nic one nie oznaczają, bo widoczne różnice są dopiero przy zmianie Majora, a są one i tak drobne.

      Podsumowując – szybszy plan wydawniczy nie musi pociągać za sobą szybkich skoków numeracji.

    • sieciobywatel

      Według Twojej terminologii, „majorów” już nie będzie. Nie będzie nagłych zmian. Czyli numeracja musiałaby wyglądać: 4.1, 4.2, 4.3, … , 4.785
      Trochę to głupie, nie?
      Nie jest ważne, jaki numerek masz. Ważne jest na jakim jesteś kanale i czy masz aktualną wersję (ewentualnie data jej wydania).
      Rozumiem przyzwyczajenia, ale moim zdaniem to znacznie naturalniejsze rozwiązanie.

    • Alexy

      I znowu: nie nagłe zmiany, a duże zmiany. Porównaj sobie Firefoxa 1.0, 2.0, 3.0, 4.0. Widać różnicę wizualną jak i w działaniu, funkcjonalności, koncepcji. Teraz porównajmy 4.0, 5.0 i 6.0… Różnice drobne, idealne do podbicia Minora, nie Majora.

      Jasne, że nie jest ważne jaki numerek mam, bo liczą się możliwości programu. Działania Mozilli w tej kwestii jednak odebrały jakiejś magicznej aury przy wydaniu wersji oznaczonej większym Majorem. Teraz mi osobiście jest obojętne, czy mam FF 4 czy 6. Tak samo jak obojętne mi jest czy mam Operę 11.50 czy Operę 11.51, ale podświadomie będę wiedział, że Opera 12.0 wprowadzi jakąś sporą zmianę, większą-nową funkcjonalność.

    • sieciobywatel

      No może i już nie będzie tak „magicznie”, ale tak czy siak byłoby to sztuczne, bo nie ma żadnych powodów, żeby wersja 9.3 nie wprowadzała większych zmian niż np. 10.0. Teraz to tylko kwestia ficzerów… Na szczęście, jeżeli kogoś to interesuje, to co robią Nicolas Nethercote (odpowiedzialny za projekt MemShrink) czy Adreas Limi (człowiek dowodzący pracami na UX Firefoksa), czy w końcu ludzie z teamów optymalizujących js – to powoduje, że na każdy kolejny update czekam wciąż niecierpliwie.
      Tak jak obecnie czekam na 27 września, aby przesiąść się na stałe Firefoksa 9, ze wszystkimi smakowitościami jakie zostały dodane przez ostatnie pięć tygodni.

  • http://www.filmweb.pl/user/SilesiaVratislaviahttp://gplus.to/gumienny Michał Gumienny

    Jak dla mnie to za tydzień może być nawet Firefox 150. Mało mnie interesuje jaki numerek ma moja przeglądarka, byle była zawsze aktualna, w pełni sprawna i rozwijana w dobrym kierunku. Wtedy mogą sobie przyjmować numery jakie tylko zapragną bądź też całkiem je zlikwidować.

  • Adrian

    Całkowicie zgadzam się z przedmówcą !

  • ninja

    FF7 działa wreszcie tak jak powinien !! spokojnie możecie pobierać i cieszyć się serfowaniem. przesiadłem się z Chroma który nie otwiera wszystkich stron tak jak powinien :/

    W nowym lisku brakuje mi jeszcze synchronizacji rozszerzeń, ale to chyba będzie można wprowadzić wraz z pojawieniem się dodatków w jetpack?

    Fajnie jak by zrobili pasek adresu i wyświetlanie kart w jednej linii (lisek zabierałby mniej miejsca) ale i tak jest miodzio :)))