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:
| Csatorna neve | Régi verzió | Firefox/Chrome megfelelő | Frissítési gyakoriság | Kiknek ajánlott |
| Stable | végleges | Release/Stable |
Kiadási ciklusonként (egy-másfél havonta) |
Átlagos felhasználóknak, akik csak használni akarják a böngészőt. |
| Next | béta, RC | Beta/Beta | 1-2 hetente | Bárkinek, aki kíváncsi, van ideje, és ért annyira a dolgokhoz, hogy el tudja magyarázni a hibát, amit tapasztalt. |
| Developer | lab, alfa | Aurora/Developer | Hetente | Fejlesztőknek, kockáknak, hozzárétőknek. |