A böngészők kiadási naptára ezen a héten megváltozott, méghozzá mindenkinél egyszerre. A Mozilla szeptember 1-jén adta ki a Firefox 155-öt, két héttel korábban az eredeti szeptember 15-i dátumnál, az új kéthetes ütem első kiadásaként. A Google szeptember 2-án léptette a Chrome 154-et a Beta csatornára a saját új menetrendje szerint, a Chrome 153 Stable pedig szeptember 8-án érkezik. A Microsoft járt elöl: az augusztus 27-i Edge 152 volt az első kéthetes Stable kiadása.
2021 óta a világ webforgalmának nagy részét hordozó három böngésző mindegyike nagyjából négyhetente adott ki új főverziót. Ettől a hónaptól ez az időköz a felére csökken.
Ki mit jelentett be, és mikor
Semmi sem érkezett bejelentés nélkül, de a három bejelentés hat hónapra oszlott el, ezért volt könnyű elsiklani az együttes hatásuk felett.
A Google március 3-án tette közzé a tervet a Chrome for Developers blogon. A Chrome 153-tól kezdve kéthetente jelenik meg új Beta és új Stable kiadás Desktop, Android és iOS platformon. A Dev és a Canary csatorna nem változik. A mérföldkövek közötti heti biztonsági frissítések folytatódnak. Az Extended Stable, az a csatorna, amelyhez a legtöbb vállalati rendszergazda rögzíti a gépparkját, nyolchetes ciklusban marad. A blog saját táblázata mutatja, mennyit mozdult a naptár: a Chrome 153 Stable eredetileg szeptember 22-én lett volna esedékes, most szeptember 8-án jelenik meg; a Chrome 154 október 20-ról szeptember 22-re kerül.
A Microsoft június 11-én követte. Az augusztus 27-i Edge 152-től a Stable csatorna kéthetes ütemre vált, és a cég egyértelműen megfogalmazta, mit jelent ez mennyiségben: minden Stable kiadás nagyjából feleannyi változást tartalmaz, mint a régi havi. Az Extended Stable megtartja nyolchetes ritmusát, és mostantól minden negyedik kiadást veszi át, így a 156, a 160 és a 164 a következő Extended Stable mérföldkövek. A Microsoft azt tanácsolja a szervezeteknek, hogy egy csoportot kísérleti jelleggel futtassanak Beta vagy Enterprise Preview csatornán, hogy a problémák még azelőtt felszínre kerüljenek, hogy a Stable eléri az éles környezetet.
A Mozilla volt az utolsó, és a legóvatosabb. Sylvestre Ledru, a Mozilla mérnöki igazgatója júliusban azt írta a dev-platform levelezőlistán, hogy a cég „planning to move Firefox Desktop and Android from a 4-week release cadence to a 2-week release cadence starting in September 2026.” Magyarul: azt tervezi, hogy a Firefox Desktop és Android kiadási ütemét 4 hetesről 2 hetesre állítja át 2026 szeptemberétől. A The Register július 17-én számolt be a változásról, és megjegyezte, hogy a Mozilla kísérletként írja le, amelyet vissza is vonhat. A Mozilla Support Blog augusztus 19-én erősítette meg a dátumokat: a Firefox 155 szeptember 1-jén jelenik meg az első kéthetes kiadásként, azzal a kifejezett kikötéssel, hogy a gyorsabb ütem „doesn’t mean Firefox will ship twice as many features.” Magyarul: nem jelenti azt, hogy a Firefox kétszer annyi funkciót fog szállítani. A Firefox ESR-t, az éves, hosszú támogatású ágat ez nem érinti; a The Register szerint a Firefox 153 lesz a következő ESR-alap.
Mi jelent meg valójában ezen a héten
A Firefox 155 hasznos próbája annak, igaz-e a „feleannyi változás, kétszer olyan gyakran” elv. A szeptember 1-jei kiadási jegyzet felsorolja az AI-alapú Smart Window kiterjesztését az USA-ra, Kanadára és Franciaországra, a blokkolt nyomkövetők számlálóját a címsorban, a konténerek átrendezését a Beállításokban, valamint javításokat a háttérben lejátszott hang megszakadására és egy régóta fennálló Linux-hibára, amely miatt a gépek egy böngészési munkamenet után nem tudtak alvó állapotba lépni.
Az MDN-en rögzített fejlesztői változások azok, amelyek a webhelyeket érintik. A CSS attr() függvény mostantól bármely tulajdonságban működik, típusos értékekkel és tartalék értékekkel, nem csak a content esetében. Két új CSS-függvény, a progress() és az alpha() érkezik a font-width mellett, amely a font-stretch új neve. A JavaScript a Promise.allKeyed() és a Promise.allSettledKeyed() metódussal bővül. A sikertelen modulimportok már nem kerülnek gyorsítótárba, így egy instabil hálózaton elbukott szkript újrapróbálkozáskor sikerülhet. Hálózati oldalon a Firefox 155 a Happy Eyeballs 3-as verzióját valósítja meg az IPv6- és IPv4-kapcsolatok párhuzamos versenyeztetéséhez, és a QUIC 2-es verzióját egyezteti a HTTP/3-hoz.
Ez nem drámai, és éppen ez a lényeg. A Google kimondott indoklása szerint „the smaller scope of these releases minimizes disruption and simplifies post-release debugging.” Magyarul: e kiadások kisebb terjedelme minimalizálja a fennakadásokat és egyszerűsíti a kiadás utáni hibakeresést. A Firefox 155 pedig pontosan ilyen kiadásnak tűnik: néhány platformbővítés, néhány javítás, két hét alatt kiadva.
Miért lépett mindhárom ugyanabban az időszakban
A Google és a Microsoft közös Chromium motort használ, így amint a Chrome menetrendje megváltozott, az Edge-é is követni fogta. A Mozilla indoklása a The Register beszámolója szerint gyakorlatiasabb volt: az elkészült funkciók heteket vártak a következő kiadási „vonatra”, és a közbeeső, kiszámíthatatlan pontkiadások sorozatához nehezebb volt tervezni, mint egy rögzített kéthetes ritmushoz.
A Chrome 2021-ben tért át a hathetes kiadásokról a négyhetesre, 2023-ban pedig heti biztonsági frissítéseket vezetett be; a két hét ugyanannak az iránynak a következő lépése.
Mit jelent ez az Ön vállalkozása számára
Az Ön webhelye mostantól nagyjából kéthetente találkozik új böngészőmotorral. A legtöbb webhely számára ez láthatatlan, és annak is kell maradnia. A böngészőgyártók éppen azért végeznek kompatibilitási teszteket, hogy egy verzióváltás ne törje el az oldalakat. Ha az Ön webhelye egy adott gyártóspecifikus viselkedésre, verziószámokat vizsgáló polyfillre vagy elöregedett külső widgetre épül, akkor az „egy változás bekerül a Beta csatornába” és az „egy változás az ügyfelei elé kerül” közötti időablak nagyjából négy hétről háromra szűkült.
A Beta csatorna a korai figyelmeztető rendszer, és ingyenes. A Chrome minden Beta kiadást három héttel a hozzá tartozó Stable előtt ad ki. A Microsoft vállalatoknak szóló tanácsa egy marketingwebhelyre ugyanúgy érvényes: tartson egy gépet vagy egy böngészőprofilt a Beta csatornán, és kéthetente kattintsa végig a pénztárat, az űrlapokat és a foglalási folyamatot. Ez olcsóbb, mint egy ügyféltől értesülni arról, hogy nem működik a fizetés gomb.
Az analitikában ugrást keressen, ne trendet. Ha egy böngészőfrissítés eltör valamit, azt egy adott napon teszi. Bontsa a konverziós arányt böngésző és verzió szerint az analitikai rendszerében, és keressen hirtelen visszaesést, amely egy kiadás napján kezdődik, és csak egyetlen böngészőt érint. Ez a minta a kompatibilitási hiba ujjlenyomata.
Tartsa naprakészen a saját függőségeit. A gyors böngészőciklusokkal jellemzően azok a webhelyek küzdenek, amelyek több évvel elmaradt JavaScript-keretrendszert, CMS-t vagy bővítményt futtatnak. Ezeknek az eszközöknek a gyártói a jelenlegi böngészőkkel tesztelnek, nem a saját, több évvel ezelőtti termékükkel. Ezt a karbantartási ritmust építjük be minden általunk átadott webhelybe: a függőségek rögzített ütemterv szerinti felülvizsgálatát, nem akkor, amikor valami elromlik.
A vállalati géppark nagyrészt érintetlen marad, és ez számít, ha nekik értékesít. A Chrome és az Edge egyaránt nyolc héten tartja az Extended Stable csatornát, a Firefox ESR pedig éves marad. Ha az Ön ügyfelei felügyelt eszközökön dolgozó vállalati felhasználók, ők kevesebb motorváltozást látnak majd, mint a nagyközönség, és a kéthetes Stable kiadásban megjelenő funkciók akár két hónap múlva érnek el hozzájuk. Ne építsen landing page-et vadonatúj CSS-funkció köré olyan közönségnek, amely novemberig nem fogja látni.
Olvasatunk szerint ez jó hír a web számára, és valamivel több munka azoknak, akik a rajta lévő webhelyeket karbantartják. A kisebb, gyakoribb kiadásokat könnyebb hibakeresni és gyorsabb javítani. Az ár az, hogy a böngészőkompatibilitás „nagyjából havonta” történő ellenőrzésének régi szokása már nem illeszkedik a valósághoz. Tegyen kéthetente ismétlődő emlékeztetőt a naptárba; ez a munka nagy része.
