Firefox krijgt dubbel zoveel nieuwe versies

Mozilla gaat dubbel zoveel nieuwe releases van Firefox uitbrengen. In plaats van elke vier weken komt er vanaf september elke twee weken een nieuwe versie. Dat begint met versie 155 op 1 september.

Het gaat om een experiment, schrijft een topman van Mozilla. Dit geldt voor de versies van Firefox voor desktop en Android. "Het doel is om ervoor te zorgen dat werk dat klaar is voor release vaker de kans krijgt om gebruikers te bereiken, terwijl het releaseproces voorspelbaarder wordt en de druk op updates afneemt", aldus de topman.

De bedoeling is niet dat ontwikkelaars twee keer zo hard moeten werken aan de browser. "Dit betekent niet dat al het werk twee keer zo snel moet worden opgeleverd. Werk dat nog niet klaar is, moet niet worden overhaast, en functionaliteit kunnen nog steeds de tijd krijgen die ze nodig hebben om te worden ontwikkeld."

Daarmee volgt Mozilla andere browsers. Google Chrome krijgt vanaf september elke twee weken een nieuwe versie en Microsoft Edge volgt dat voorbeeld. Apple Safari krijgt elk jaar een grote update en tussentijdse updates elke één of twee maanden.

Firefox stock. Bron: Thomas Fuller/SOPA Images/LightRocket via Getty Images

Browser Reguliere releasecyclus
Google Chrome Elke 2 weken vanaf september
Microsoft Edge Elke 2 weken vanaf september
Mozilla Firefox Elke 2 weken vanaf september
Apple Safari 1x per jaar (grote upgrade), plus tussentijdse updates (om de 4-8 weken)

Door Arnoud Wokke

Redacteur Tweakers

12-07-2026 • 09:07

42

Submitter: KipKroket

Reacties (42)

Sorteer op:

Weergave:

Wie is degene die bedacht heeft dat werkelijk elk stukje software agile met 2-wekelijkse releases moet werken?
Het is inderdaad meestal nergens voor nodig, maar ja, iets met tijdsgeest en tunnelvisie enzo.
Zo raar is dit niet.

Bij ons op werk releasen we soms meerdere malen op een dag. Dat kan omdat we dat hele proces geautomatiseerd hebben en bijna alles met testen dekken. Stel dat er wat misgaat is het ook zo teruggedraaid.

Het is gewoon niet handig dat allemaal op te sparen. Stel dat er wat misgaat kan je gaan zoeken naar welke change daar verantwoordelijk voor was.
Ik vind het eerlijk gezegd in veel gevallen ook vooral een symptoom van doorgeslagen IT management, die vergeten is waar men eigenlijk voor is aangesteld: het bedienen van gebruikers.

Als eindgebruiker zit ik met veel software, kijkende naar u, Microsoft, helemaal niet te wachten op continue verandering. Weten wat je hebt en voorspelbaarheid is daar juist een pre. Ik heb als eindgebruiker, wat ook ik als IT’er, helemaal niet de capaciteit me bij wijze van spreken wekelijks, laat staan dagelijks, me er bezig mee te houden wat er eventueel veranderd is in welke applicatie.

Liever eens in de zoveel tijd een big bang met wat begeleiding, in plaats van continu nieuwe zaken over de schutting te krijgen onder het mom van “mocht er wat zijn horen we het wel”.

Met Firefox geloof ik het ook al jaren. Nog altijd mijn go-to, maar om nu iedere keer wanneer ik de boel opstart eerst een changelog te lezen, nee dank u. Noem me ondankbaar, maar het effect is dus dat er ergens een glunderende release manager zit die eigenlijk z’n doel met een Jaap Stammetje voorbij schiet.

Aan de andere kant krijgt Firefox nu iedere keer weer meer exposure op dus websites als tweaksers, waar ik als eindgebruiker dus indirect wel van profiteer.
Meermaals per dag releasen is niet raar, wat jij beschrijft wel, dat is gewoon direct releasen na opleveren, zonder dat er ook maar een test ronde aan pas komt.
Ook met agile wordt er gewoon getest, alleen kun je zo gerichter testen. Bovendien bevorderd het telkens opleveren de kwaliteit doordat er sneller en meer getetst moet worden
Hangt wel van de applicatie af. Ik heb helaas ook agile releases gezien die teruggedraaid moesten worden omdat er elders iets kapot ging. Het probleem was agile opgelost, maar een nieuw probleem ontstond daardoor. Zeker met oudere applicaties die niet vanaf de grond af aan ontworpen zijn met agile in gedachte is dat een dingetje.

Overigens kan het ook een dingetje zijn met applicaties die in de basis hiervoor goed ontworpen zijn, maar waar tussentijds te veel vrijheid gelaten is, en zaken niet volgens de opgezette standaarden gedaan zijn. Zeker als je met meerdere teams werkt is die discipline van belang.
Zo raar is dat niet als de testers onderdeel zijn van de code merge proces en er een goede test suite is.
Alles wordt wel degelijk getest, hoe maak jij er dan weer van dat dat ineens niet zou gebeuren?
Precies, waar het probleem hier zit, gaat er iets mis door het te snel releasen, dan hebben miljoenen gebruikers er last van die allen enorm veel data moeten binnen halen uit app stores om dat weer te repareren.

En we hebben met het Crowdstrike debakel gezien wat het betekend als een stukje software op heel veel apparaten staat en waar het fout gaat.

Dat betekend niet dat je niet dagelijks meerdere keren kunt releasen, maar je moet wel meenemen voor wie, waar en hoe je released. Bij jullie op het werk is de doelgroep van je releases iets heel anders dan een browser die wereldwijd beschikbaar is.
Dat Mozilla hier iets van vind, kan ik me voorstellen, maar horden gebruikers worden hiermee onnodig belast. Vooral omdat andere "experts" hier ook iets van vinden (bijvoorbeeld de bank, want de browser moet veilig).

Ik heb met de laatste versie van Firefox-ESR nu al dat de bank klaagt dat ik "de laatste versie" moet installeren. Blijkbaar acht de bank de kans op een hack bij de reguliere versie kleiner dan bij de ESR-versie. De ironie zal niemand hier ontgaan.
Bij welke bank is dat? Rabo en mijn Duitse bank hebben er nog nooit over geklaagd. En ja ik draai al vanaf het begin met de ESR versie.
ASN in elk geval; had het op mijn oude MacBook laatst, met de meest recente ESR van FF. Die versie van macOS kon echter ook de 'gewone' release installeren dus dat maar gedaan; melding verdwenen. Terwijl eigenlijk alle andere sites prima werken.
Ik heb met de laatste versie van Firefox-ESR nu al dat de bank klaagt dat ik "de laatste versie" moet installeren. Blijkbaar acht de bank de kans op een hack bij de reguliere versie kleiner dan bij de ESR-versie. De ironie zal niemand hier ontgaan.
Tweaker workaround:
User-agent spoofing. Daar zijn extensies voor om het makkelijk en sitespecifiek in te richten.

[Reactie gewijzigd door The Zep Man op 12 juli 2026 09:56]

Ze hebben in de laatste release 400+ fixes gestopt, meeste door AI aangeleverd. Snellere release om gaten te dichten. Hopelijk tijdelijk tot alles weer redelijk rustig is.
Ik vind het ook altijd raar, gewoon lekker continu releasen en zorgen dat je gebruiker er geen last van heeft.
Ook continu releasen vind ik meestal nergens voor nodig,
Juist wel nuttig.
Zo komen functionaliteiten eerder naar de gebruiker. Je hoeft immers niet te wachten tot een grote release.
Tegelijkertijd weet je fouten/bugs, eerder waar het aan ligt. Immers, als je ineens 40 dingen veranderd of maar 2 dingen veranderd, dan weet je beter waar je moet zoeken.
Tevens ben je voorspelbaarder in gedrag,wat voor bedrijfsleven handig is, prive wellicht minder.

Ik zie alleen maar voordelen
Grappig, ik juist wel. Ik vind het de oplossing voor allerlei problemen. Maar goed wat je zelf prettig vind. Ik vind zelf updates met dit soort programmas totaal niet interessant, dus wil liefst dat ze lekker op de achtergrond updaten en val me niet lastig
Agile schrijf helemaal niet voor dat sprints 2 weken moeten zijn. Agile schrijft wel voor dat je zelf bepaalt wat de beste cadans is voor je organisatie. En een sprint staat ook niet gelijk aan een release, er zijn bedrijven die dagelijks releases doen.
Of meermaaldaags in ons geval. Releases staan verder los van onze sprints en planningen. Maar dit betreft een webapp die we op eigen servers installeren. Software die bij klanten draait is een ander verhaal, die releases werken anders.
Waarom niet gewoon meerdere keren per dag? en dan gewoon stoppen met de versienummers die nergens op slaan. Firefox versie 26.7.12.9.59 is niets mis mee. En dan lekker alles achter feature toggles (wat Firefox al wel goed doet)
Nee dit is vast ingegeven door de boost die ‘AI’ geeft in het vinden en exploitatie van bugs. Je zal dit bij alle serieuze software bedrijven gaan zien dat ze meer en vaker patches uitbrengen om de wedloop met de hackers voor te blijven.

Met behulp van ‘AI’ worden meer en sneller bugs gevonden en de ‘AI’ kan zelfs de code schrijven om het te misbruiken. Iedereen die een beetje serieus is qua cyber security is nu bezig te zorgen dat ze deze verandering in dynamiek kunnen blijven volgen en software leveranciers moeten alle zeilen bij zetten om zo snel mogelijk en veel mogelijk bugs op te lossen en te releasen.
Ik kan me niet voorstellen dat er niet minimaal elke twee weken een boel bugs worden opgelost met impact op de beveiliging van deze browser.

Prima aanpak dus!
Een bugfix kan toch altijd tussendoor?
En Firefox doet ook gewoon patch releases met (belangrijke?) bugfixes en security fixes, "tussendoor" aan de major releases. Dus nu met elke 4 weken een major (.0) release kan het ook dat de vorige major bv nog 3 patch releases heeft gehad, dus een .3 versie.
... een major (.0) release
bij Semantic versioning is een Major geen (.0) maar (0.) denk dat je hier Minor bedoelde.
https://semver.org/
Je weet alleen nooit of de bugfix niet iets anders stuk heeft gemaakt.
Hoe release je met dat mantra? 🤔
Op een andere manier testen beperkt het risico. Probleem is, de testsuite is vaak gebouwd/geschreven op basis van de flows die je kent tijdens de ontwikkeling.

Heel simpel voorbeeld, een rapport werkt gewoon, maar je kunt er ook een filter in toepassen. In de bron veranderd iets, het rapport kan opgevraagd worden en geeft de verwachte test set als antwoord, en toch komt er een klacht, want een van de filters geeft een onverwacht resultaat. MIsschien had je 100% van je code in de test gedekt moeten hebben en het dan gevonden, of misschien is het in de data bij de bron waar iets veranderd waar je code niet op voorzien had. Moraal van het verhaal, ook testen is niet 100% garantie.

En dan het mantra, na release zorg voor capaciteit om fouten op te lossen, dus release nooit als je 5 minuten daarna naar huis gaat weekend/vakantie vieren.
Als men hier zelf voor kiest wilt dat ook meestal zeggen dat het nodig is. Kan zijn dat bvb dat verbeteringen wat meer verspreid geraken, dat men sneller kan anticiperen op de markt. Zolang het dev en qa team het zien zitten is vaker releasen vaak beter in software land.
Ik vind update prima maar wordt wel beetje moe van dat eindeloze UX tuning. Van de meeste icoontjes heb ik nog steeds geen idee wat ze doen. Wat is mis met gewoon tekst. Het is niet dat functie van de browser nou zoveel anders sinds het begin. (Bewaar bladwijzer en het tonen van een webpagina)
Begint te klinken als: updaten om het updaten.
Klinkt als een goed CI/CD proces
Nu kan ik elke twee weken de snelkoppeling weer van m'n bureaublad van halen...
Volgens mij is dat al een paar versies geleden dat het eruit gesloopt is, het is dat je het zegt, want het was mij niet opgevallen. Ik heb al een tijdje geen snelkoppeling gezien iig.
Hopelijk kunnen ze dan ook maken dat het niet de browser sessie hoeft te onderbreken of dat je niet continu met updatemeldingen doodgegooid wordt.
Omdat de rest het doet gaan wij het ook doen dus. Tenzij het security updates betreft is dit echt nergens voor nodig. En dan telkens dat extra tabblad open voor de gebruiker met alle changes waar je in de praktijk toch niks van gaat merken
Als power user is het wel vervelend. Ik heb vaak mijn standaard sessie open staan, en Private Browsing. Soms ook nog een andere profiel (geopend via about:profiles).
Als er een update is, moet je alle schermen sluiten alvorens je kan verder surfen. Dat wil dan ook zeggen dat je je sessie in de Private Browsing op dat moment kwijt bent.
Irritant.
Dat telt uiteraard ook voor de kleine versie upgrades. Maar hoe meer updates, hoe meer ik hier tegenaan loop...
Op Linux hoeft dat niet, dan installeer je gewoon de update welke actief wordt ala je zelf de browser opnieuw opstart

Om te kunnen reageren moet je ingelogd zijn