Az Opera a mai nappal, a 17 Dev verzió megjelenésével állt át rendesen a Chrome és a Firefox által is használt, úgynevezett gyorsított kiadási ütemezésre. Lássuk, hogy miből is áll ez a váltás!

Az Opera korábban a "klasszikus" kiadási ütemezést követte. Ez azt jelentette, hogy a fejlesztők belső összeállítások sokaságán tesztelték a fejlesztéseket, majd amikor úgy érezték, hogy az előre megtervezett funkciócsomag már működőképes, akkor kiadtak egy alfa verziót, és onnantól átálltak a fejlesztésről a hibák javítására. Ebben a fázisban tudtak bekapcsolódni a felhasználók azzal, hogy telepítették az alfa verziót, és a mindennapi használat közben előjött hibákat jelezték a fejlesztőknek.

Ezt követte egy vagy több béta és kiadásra szánt (RC) verzió közzététele, amik jó esetben már csak kisebb hibákat tartalmaztak, és általában mindennapi használatra is alkalmasak voltak. Az alfa és a végleges, stabil összeállítás kiadása között viszont sokszor több hónap is eltelt, hiszen egy-egy verzió több funkciót és újdonságot is tartalmazott.

Az iparág azonban felismerte, hogy a web fejlődési üteme mellett ez a stratégia nem tartható, ezért kialakult az a stratégia, amit ma gyorsított kiadási ütemezésnek nevezünk. A jelmondat az, hogy "adj ki kevesebbet gyakrabban", de a stratégiaváltás valójában többről szól. Az alábbi három jelentősebb változás következett be.

Az első természetesen az, amit a jelmondat is megfogalmaz. A fejlesztők a tervben lévő fejlesztéseket kisebb csomagokra osztják, így a gyorsabban elkészülő fejlesztéseknek nem kell a fiókban várni a lassabban elkészülőkre. Ez teljesen logikus, hiszen ha valami már készen van, akkor adjuk oda a felhasználóknak minél hamarabb. Egy ilyen gyorsított ciklus általában egy-másfél hónapot jelent.

A második változás a verziószámozást érinti. Sok szakmabelit és felhasználót megbotránkoztatott, hogy az évtizedek óta megszokott számozást a kukába dobva, havonta növelik a verziószámot a gyártók. Ami korábban 15.1 lett volna, az most a 16-os számot kapta. Ez azonban csak marketing fogás, semmilyen funkcionális dolog nincs mögötte. A nyilvántartás korábban is az összeállítások számozása alapján történt, bár az tény, hogy a verziószám több információt rejtett magában. Ez azonban, ahogy írtam, csak marketing, nem érdemes vele bővebben foglalkozni.

A harmadik változás az összeállítások elnevezését érinti. A korábbi alfa és béta verziók helyett bevezették a kiadási csatornákat. Ezek a csatornák egymástól függetlenül telepíthetők és használhatók. Jelen esetben egymás mellett böngészhetünk a stabil 15-ös verzióval, tesztelhetjük a 16-os Next verziót, és próbálgathatjuk a 17-es Dev verziót.

A Dev csatorna olyan már működőképes, de még fejlesztés alatt álló funkciókat tartalmaz, amiket lehet már próbálgatni, de még nincsenek teljesen készen, és bármelyik pillanatban összeomolhat tőlük a böngésző. A Next csatorna olyan funkciókat tartalmaz, amik már késznek tekinthetők, de lehet, hogy még hibásan működnek. Odafigyeléssel akár mindennapos használatba is vehetők, de nincs kizárva, hogy előfordul valami probléma. A stabil csatorna az, ami bárki számára használható a mindennapi böngészéshez. Elvileg nem tartalmaz hibát. (Gyakorlatilag igen.)

A Developer és Next csatornák közötti fontos különbség az, hogy a Developer verziókba bármelyik frissítéskor kerülhetnek új funkciók, míg a Next verziók már lezártnak tekinthetők. Új funkciókat már nem kapnak, csak a meglévő hibákat javítják.

Az alábbi táblázat összefoglalja a legfontosabb ismereteket a csatornákkal kapcsolatban: