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 functies 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.

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)

Reacties (121)

[Tyrian]

Van mij hoeft het niet. Qua functionaliteit gebruik ik zelden functies in Firefox die nieuwer zijn dan twee jaar oud. Beveiligingsupdates kunnen normaal gesproken maandelijks tenzij er een keer een out-of-cycle patch nodig is voor een bug die actief misbruikt wordt.

Hoe vaker je updatet, hoe meer je gebruikers irriteert met herstarts. Ook riskeer je dat je als ontwikkelaar de tijd niet neemt om nieuwe versies grondig te testen.

[mocean]

Wie is degene die bedacht heeft dat werkelijk elk stukje software agile met 2-wekelijkse releases moet werken?

[zordaz]

Het is inderdaad meestal nergens voor nodig, maar ja, iets met tijdsgeest en tunnelvisie enzo.

[Barsonax]

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.

[Cid Highwind]

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.

[Robby517]

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.

Maar het allergrootste deel van die changes ga je nooit zien, dat zijn optimalisaties in de render engines, security fixes, pre requirements voor volgende grotere changes etc... Firefox updatet gewoon mooi op de achtergrond, het zet de installatie klaar en in no time is die geïnstalleerd bij je volgende browser start.


Ik snap dus het "ik heb hier als gebruiker niks aan" idee helemaal niet. Jij hebt juist wel nood aan updates.

[zordaz]

Ik heb alleen kritische fixes nodig voor software die al werkt, meer niet. Dat is heel wat anders dan continu releases.

[Robby517]

Neen dat heb je niet, het web evolueert continue, het laatste decennia zijn zaken als streaming responses, http2/3, server side events, css en html changes of standaard updates en nog zoveel meer bij gekomen. Die gebruik jij wel en zonder de updates was het web nu minder bruikbaar voor jou.

[Fathier]

Dat mag zo zijn, maar dat rechtvaardigt niet om elke twee weken een "nieuwe" versie uit te brengen. Dat is nergens voor nodig, en typisch iets wat de IT-wereld van tegenwoordig kenmerkt: met oogkleppen op als arrogante randdebielen achter elkaar aanlopen, zonder ook nog maar enig benul te hebben wat er zich in de echte wereld afspeelt, en de eindgebruiker opzadelen met de gevolgen ervan: een bagger aan ongewenste "features" die niet zijn getest (daar zijn wij immers voor) en dus talloze bugs bevat die zelfs onze apparatuur zowat bricken, en dat ook nog onder het mom ven "het verbeteren van de gebruikerservaring" een kreet die me ondertussen doet kotsen en tegelijkertijd een acute diarree-aanval teweeg brengt.

[Robby517]

Je praat echt onzin, opzadelen met de gevolgen, amper getest,.. je gebruikt gratis software... niemand verplicht je om updates te installeren, zet ze dan gewoon af in de settings. Echt wat een hoop gepriviligeerd gemekker.

[zordaz]

Ik gebruik genoeg applicaties die niets met web doen die onnodig vaak updates. Firefox ESR bewijst dat best prima zonder contine releases kan. Ik voel me daanaast vaak een veredelde beta-tester als er weer eens een onzinnige functie wordt toegevoegd aan een app. Dat is veranderen om het veranderen. Pure verspilling.

[Reactie gewijzigd door zordaz op 12 juli 2026 21:34]

[Dat_Doen_We_FF]

En toch, mijn oude firefox in Debian doet het allemaal goed.

[D.J.P.]

Het zijn niet alleen technische updates in dit geval. Firefox is een nogal commerciële koers gaan varen de laatste tijd. Zoal @Fathier betuigt zijn dat ook 'features' waar je misschien niet om hebt gevraagd zoals de recente 'Profiles' optie, ingebouwde VPN en binnenkort ook een Addblocker als het goed is. Het begint een beetje te bloaten in ieder geval.

We moeten voor de grap maar eens de installatiegrootte en lokale resource gebruik van FF in de gaten houden de komende tijd en projecteren op wat de de afgelopen, pak 'em beet, 10 jaar is geweest. Ik was altijd erg tevreden met hun minimalistische, functionele aanpak en ben benieuwd waar deze koersverandering toe gaat leiden.

[Kevinp]

Juist om jouw redenen willen wij hier ook liefst dagelijks releasen als dat zou kunnen. Een feature is klaar. Hop naar de gebruiker.

Zit er veel bij waar je mogelijk minder aan hebt kan. Maar als je browser een security lek heeft verwacht je wel een snelle update.

[Jerie]

Als eindgebruiker zit ik met veel software, kijkende naar u, Microsoft, helemaal niet te wachten op continue verandering.

[...]

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.

Begrijpelijk. Zeer begrijpelijk zelfs. En daar is ook een oplossing voor die te weinig waardering krijgt: ESR (LTS).

Ik zeg LTS want hetzelfde geldt ook voor de Linux kernel, het OS, noem maar op.

[zordaz]

Je slaat de spijker op zijn kop. Mag jij raden welke versie van Firefox ik daarom gebruik. Kritische fixes en updates komen gewoon snel door. Daar heb je echt geen continue releases voor nodig.

[Jerie]

Ja, ik gebruik Firefox met name op Ubuntu, dus ik zou juist een soort van ESR moeten hebben, maar gebruik juist nog een continuous release. Omdat ik toch regelmatig heb gehad dat er een nieuwe feature in een contineous release zit die ik toch wel behoorlijk belangrijk/prettig vind. Recent voorbeeld is WebUSB. Ben ik er gek op? Nee, absoluut niet. Standaard staat het ook uit. Maar als ik omdat ik voor een interne website WebUSB nodig heb (KVM remote) ik daar dan Safari/Chrome voor moet gebruiken, dan vind ik dat eigenlijk wel naar. Dan maar native in Firefox. Al heb je er dus ook een extensie voor.

[Marc050]

ESR = Extended Support Release (weet niet iedereen )

https://support.mozilla.org/en-US/kb/firefox-esr-release-cycle

[Reactie gewijzigd door Marc050 op 12 juli 2026 16:54]

[Llopigat]

Ja met MS Office zaten we altijd op de semi-annual, 2x per jaar een update en verder geen gezeik. Konden we het gewoon goed testen voor je de ok geeft.

Maar nu is Microsoft van: Als je niet op het monthly channel zit dan krijg je geen copilot, punt. Elk bedrijf wil halsoverkop AI AI AI dus a, we moesten wel. Het testen is natuurlijk ook het raam uit gegaan daarmee.

[linext]

Eens! En nog een nadeel van gebruik op Ubuntu met de Firefox (als snap install), deze kan pas updaten bij het sluiten van de browser en niet op de achtergrond tijdens gebruik.. Heel fijn als je het systeem intensief gebruikt en in de slaapstand zet ipv afsluiten. Dan krijg je die updates dus altijd later binnen(!). En wanneer je firefox tussendoor een keer helemaal sluit, start het update proces niet altijd direct op. Als je daar op wilt wachten of checken, moet je dit handmatig doen.

[smooc]

Snellere releases zullen overal gaan komen. Ik vermoed zelfs binnen 24u. Dat is niet feature gedreven, maar security gedreven. Iedereen is als de dood voor de lawine van "Mythos" (like) issues. Dit is dus een manier om gebruikers te laten wennen aan snellere en veel vakere updates.

[mickvdv]

Als eindgebruiker, in de huidige tijd, heb je zeker wel de wens voor snelle updates. De hoeveelheid CVE's die er de laatste tijd gevonden wordt, geeft je simpelweg geen keus meer. Waar je vroeger met een maandelijkse patch nog wel even kan wachten, is dat nu echt een steeds groter risico aan het worden.

Natuurlijk vereist dit een goede (automatische) testaanpak, waardoor de kwaliteit van de releases niet achteruitgaat. Maar gegeven dat aan die eisen voldaan is. Is het risico van 15 kleine releases, een stuk kleiner dan één grote.

En als je het niet wilt, kan je het toch altijd uitzetten?

[Gropah]

Ik denk dat je wellicht iets anders vergeet, namelijk security.

De browser is steeds belangrijker geworden. In de tijd van de inbelverbinding had je hem alleen draaien als je op het internet zat, en dan nog niet eens altijd. Nu draait altijd wel iets van een browser op een computer. En het is dan ook een belangrijke attack vector geworden. Zero-days in browsers zijn enorm veel geld waard op de zwarte markt. Daar komt ook nog eens bij dat het met speciaal ontwikkelde modellen voor LLMs, zoals Fable, makkelijker is geworden om een exploit te vinden (en waarschijnlijk ook om te exploiten). Om die lekken te dichten zijn releases nodig.

Je kunt dan met patch versies gaan werken (de z in x.y.z van semver), maar niet iedereen is daar fan van. Van wat ik heb begrepen zou dat zijn omdat het minder voorspelbaar is (niet elke versie y krijgt een .1 of .2). En als je mensen zsm over wilt op nieuwe versies vanwege veiligheid, kan ik mij voorstellen dat dat makkelijker gaat als je ook iets van nieuwe functionaliteit toevoegt.

[faim]

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.

[readefries]

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

[swhnld]

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.

[readefries]

Juist als er andere kant iets omvalt zou een teken moeten zijn dat er iets mis is met de architectectuur van de app.

In mijn ogen is discipline niet het probleem, maar ownership. Juist met vrjjheid neemt dat toe is mijn ervaring, met als gevolg stabiliteit.

En 'goed' ontwerp is in mijn ogen niet geborgd met de architectuur die uitgadacht is met waterval; juist goed 'ontwerp' ontstaat door ownership (in mijn ogen door ervaring en cohesie van 't team). Juist dat laatste zie ik maar al te vaak missen in papierenwerkelijkheden die een 'architect' bedenkt. Ja ik heb een aversie tegen die rol, in mijn ogen zijn die vaak weggegroeid van de werkelijkheid en stoelen daar toch ADRs mee vol. Welke in mij ogen júíst door en met ontwikkelaars moeten worden vastgesteld.

[rjmno1]

Ik gebruik firefox zolang totdat ik weer op deze website zit en dus zie dat er een nieuwere versie uit is, en dan update ik hem weer.

Want er komen nu al best veel releases uit voor firefox.

[Barsonax]

Alles wordt wel degelijk getest, hoe maak jij er dan weer van dat dat ineens niet zou gebeuren?

[faim]

Omdat jij zegt dat alles geautomatiseerd is, daar maak ik uit op dat er dus geen QA'er oid aan te pas komt.

[Barsonax]

We werken niet met dedicated QA'ers maar we testen alles door en afhankelijk van context zitten daar gebruikers testen bij (uiteraard kost het dan meer tijd dus werk je met feature flags oid).

De automation slaat meer op alles eromheen wat we zoveel mogelijk geautomatiseerd hebben. Je wilt niet lopen klooien met handmatig een zipje naar een server kopiëren oid.

[Reactie gewijzigd door Barsonax op 12 juli 2026 13:25]

[Caelorum]

Zo raar is dat niet als de testers onderdeel zijn van de code merge proces en er een goede test suite is.

[swhnld]

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.

[Barsonax]

It depends natuurlijk. Een browser die wereldwijd gebruikt wordt loopt tegen andere problemen aan dan een SaaS product.

Maar vaak releasen is niet raar, je moet wel je process erop inrichten en natuurlijk het niet zo maken dat gebruikers elke keer weer een gigabyte aan data moeten binnenhalen.

[jeroen79]

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.

Misschien is dat handig binnen je ontwikkel- en testomgevingen maar in je productieomgeving is rust (voor de gebruiker) ook handig.

[MadJo80]

Jullie krijgen tijd om de regressietesten bij te werken?! Ik ben in mijn team de enige tester, ik mag zowel het handmatige werk doen, als (bij gratie gods) af en toe de regressietesten bijwerken.

[Barsonax]

Krijgen? We nemen die tijd gewoon. Hoort gewoon bij het werk.

Wachten totdat de business oid prioriteit gaat geven aan het schrijven van tests betekent dat dat nooit gaat gebeuren. Gelukkig met TTD is het gewoon hoe je werkt.

[Dat_Doen_We_FF]

Als je zoveel versies nodig hebt dagelijks, vraag ik mij af hoeveel bugs er dan wel niet in je codebase zit die je heel de dag aan het fiksen bent.
En als het nieuwe functies zijn, denk ik weer aan bugfixes.

CI/CD is allemaal leuk en aardig, maar wtf?

[specs2021]

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.

[Z80]

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.

[bvanwijk]

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.

[R4gnax]

ASN in elk geval

ASN is dan ook compleet doorgeschoten. Zelfde met hun achterlijke verplichting voor het gebruik van biometrics om rekeninghouders te identificeren (KYC). Daar zit gewoon iemand verantwoordelijk voor het security-beleid die de grip op de realiteit langzaamaan kwijt is.

[Reactie gewijzigd door R4gnax op 12 juli 2026 11:16]

[LooneyTunes]

ASN is dan ook compleet doorgeschoten. Zelfde met hun achterlijke verplichting voor het gebruik van biometrics om rekeninghouders te identificeren (KYC).

En voldoe je daar aan, gaan ze nog steeds door met mailtjes sturen.
En gijzelen ze inderdaad je rekening.
Ik zit er pas een paar jaar (2022), maar dit soort idioterie heb ik in ~45 jaar Postbank/ING nog nooit meegemaakt.

[specs2021]

De browser-check heb ik last van. De biometrics check nog niet (SNS is nog niet zover).

Maar als ik dat zo hoor moet ik weer eens gaan shoppen voor een andere bank.

[zordaz]

Ik denk eerder dat ze niet weten wat Firefox ESR is. Heb er hier idd ook last van bij ASN.

[The Zep Man]

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]

[R4gnax]

Als een bank slimmigheden doet zoals daadwerkelijk de user-agent staven aan de DOM APIs die beschikbaar zijn, kunnen ze ook zien dat de user agent gemanipuleerd is. Dat kan op zich signaal zijn dat er iets niet pluis is en dat de verbinding geweigerd wordt. Het kan ook vastgelegd worden voor de toekomst - en het feit dat je een browser gebruikt met gemanipuleerde user agent string met een bewust afwijkende versie kan tegen je gebruikt worden als zijnde het ontwijken van de beveiligingsmaatregelen en doelbewust tegen de instructies van de bank in handelende een oude versie gebruiken. Dat kan als je ooit problemen krijgt met een geplunderde rekening, betekenen dat ze je niet schadeloos gaan stellen. Dus- voorzichtigheid geboden.

[arnovr]

Ik vind het ook altijd raar, gewoon lekker continu releasen en zorgen dat je gebruiker er geen last van heeft.

[WillySis]

Ik heb op mijn computer(s) eigenlijk continu een browser openstaan. Een nieuwe release betekend dat alle browservensters moeten worden afgesloten, waarna de nieuwe versie kan worden geïnstalleerd en de vensters weer kunnen worden geopend. Bij het openen van de browservensters komen ze meestal op een ander virtueel scherm terecht dan waar ik ze wil hebben. Dat is samen met die één à twee minuten die ik moet wachten toch wel een nadeel.

Het voordeel is een iets vergrote veiligheid, maar meestal voor problemen die nog niet of zelden in de echte wereld gebruikt worden.

Hetzelfde geld voor office pakketten en andere grote apps.

Als een app zich op de achtergrond kan updaten, zonder dat de gebruiker het merkt is het meermalen per dag of week updaten niet vervelend, maar als open vensters moeten worden afgesloten, of de installatie van de update bij het opstarten meer dan een halve minuut vertraging oplevert, vind ik het als gebruiker irritant. Dan is één update per week wel het maximum, maar als je meerdere van dat soort apps gebruikt wordt het alsnog irritant. Dan heb ik liever dat men nightly builds beschikbaar stelt voor de liefhebbers en de updates voor de normale gebruikers opspaart en eens in de twee weken of eens in de maand naar de gebruikers pushed.

[zordaz]

Ook continu releasen vind ik meestal nergens voor nodig,

[Loft]

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

[verstrooid_prof]

je kan ook zeggen: elke gebruiker wordt betatester

want impliciet geef je aan dat er door het (te)snel doordrukken naar productie er ook bugs komen. en dat je in die (test)fase beter geholpen bent met 1 change en dus 1 bug per keer, ipv 40 changes te gelijk..

Dat is of was exact waarvoor de beta en alfa versie dienden, zodat de productiegebruiker die bugs niet zag.

[nandervv]

Bij free/opensource software is dat dan weer helemaal redelijk. Je betaalt nergens voor, dus je hebt ook nul recht van spreken.

[arnovr]

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

[stappel_]

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.

[Aalard99]

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.

[xFeverr]

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.

[elmuerte]

Agile zegt niks over cadans, zegt niks over sprints, zegt ook niks over releases.

Agile zegt wat over contact met je gebruiker/klant/opdrachtgever, zegt wat over werkende software, zegt wat over rekening houden met verandering (van inzichten, wensen, etc.).

Je kan agile zijn, en nog steeds maar eens per half jaar een versie met nieuwe features uit rollen naar productie. Je hebt in die tijd continue samengewerkt met de mensen die het gaan gebruiken, en ze hebben hopelijk ook kunnen uitproberen, voordat het in productie komt te staan.

[SilentLucidity]

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)

[mjl]

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.

[Jerie]

Rat race tussen browsers. De een gaat nog snellere release schedule, de ander volgt. Die rat race is voordelig als het in jouw ogen positieve veranderingen zijn, maar zijn ze negatief dan heb je minder keuze. Je mag hopen dat nieuwkomer Ladybird het een of ander anders aan gaat pakken, maar wellicht willen ze ook meedoen in de rat race.

[Amdk6II]

Het heeft voordelen hoor. Als wijzigingen niet goed getest zijn of mee mogen in de release set is de volgende release niet 2 maar 4 weken ver weg.

Ook releases gefaseerd doorvoeren en later ineens aanzetten of issues oplossen kan sneller zonder emergency release. Legio voordelen.

[Oon]

Is wel beter dan bijv. Discord waar ze 2-3x per jaar een update doen met hun ~300FTE aan developers waar dan alleen een minimale feature uit komt die ze meer omzet oplevert omdat het zo'n opgeblazen bedrijf is dat ze geen kant meer op kunnen en alles 100x langer duurt dan nodig.
Mooi dat Mozilla wel nog gewoon beweegt, beter vaker kleine releases zodat je grip houdt op wat er open staat en waar je naartoe wilt dan de hedendaagse standaard van meer mensen met minder output.

[baaart900]

Ik stoor me er zwaar aan dat ik iedere keer bij een update, de browser moet herstarten. Als dit nu nog vaker gaat gebeuren en dit niet op de achtergrond kan, ben ik er snel klaar mee

[Mr. M]

Dat is, voor zover ik weet, bij elke browser het geval.

Het kan zijn dat sommige andere browsers niet expliciet vragen om te herstarten, maar zonder te herstarten gebruik je gewoon de oude versie van de browser. Pas bij een herstart zal je de nieuwe versie gebruiken.

[Reactie gewijzigd door Mr. M op 12 juli 2026 14:01]

[Boekenkaft]

Je kunt settings aanpassen, zie mijn andere reactie.

[Mr. M]

Heel erg bedankt, al kan ik mij niet herinneren dat ik dit ooit heb gemerkt dat firefox mij vroeg om te herstarten nadat die zelf updates installeerde.

Maar het kan zijn dat ik dit ooit al eens heb afgezet, want mijn firefox profiel is minstens 20 jaar oud. Ik gebruikte het al van toen het nog phoenix en firebird noemde als tweede browser, al weet ik niet zeker of het mijn allereerste profiel is dat ik heb overgenomen want ik heb zeker een disk crash gehad op de eerste computer waar ik het op gebruikte met een deel dataloss als gevolg.

Edit: juist nagekeken en ik had het inderdaad al ooit eens aangeduid op beide firefox instances die ik vaak gebruik (gewoon en dev edition). Met andere woorden, ik had niet door wat baaart900 bedoelde. Ik dacht dat dit standaard werkte zoals andere browsers die ik gebruik zoals Brave.

[Reactie gewijzigd door Mr. M op 13 juli 2026 09:54]

[Swindowmasher]

Ik denk dat het meer slaat op het ding dat als er een update is, die in de achtergrond laadt, en dan plots de browser moet herstart worden want anders kan je niet verder.

Heel erg vervelend wanneer je net een formulier aan het invullen bent of zo. Zoals hieronder vermeld kan je automatisch updaten wel makkelijk uitzetten. Dat deed ik onlangs ook.

[Boekenkaft]

Dit stoorde mij ook, maar is in settings te veranderen. Nu krijg ik geen meldingen meer en update Firefox pas bij herstart en merk je er niets van.

Settings-> About firefox -> Automatically install updates (set to active) + Select: When Firefox is not running. Unselect: Check for updates, but choose when to install.

[Reactie gewijzigd door Boekenkaft op 13 juli 2026 00:45]

[Wraldpyk]

Fijn dat die instelling er is, ik had inmiddels al besloten dat ik de updates dan wel handmatig installeer want was er helemaal klaar mee dat dit blokerend werkt.

Ondertussen ben ik ook maar Vivaldi gaan testen want dit was ook wel een beetje de druppel voor me. Al zoveel websites die gewoon geen Firefox meer testen dat het een beetje ten einde lijkt te gaan.

[De Vliegmieren]

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!

[Wouterie]

Een bugfix kan toch altijd tussendoor?

[wjvh]

Je weet alleen nooit of de bugfix niet iets anders stuk heeft gemaakt.

[readefries]

Hoe release je met dat mantra? 🤔

[swhnld]

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.

[readefries]

Test coverage is een nietszeggende metric. Leuj al die unittest op getters en stetters, maar fat voegt geen waarde toe.

Grappig voorbeeld van je filter, maar dat is een architectuur probleem: iedere wijziging in het filter zou het viewModel moetdn updaten. Dat gedrag test je. Niet een specifiek filter...

En zoals ik ook schrijf in een reactie op @drfisheye hieronder: releasen die je misschien wel hondert keer per dag, maar dat betekend niet dat je een release opleverd.

[swhnld]

Wat 100% code coverage betreft, ik ben het met je eens, maar het ging er vooral om dat tegenwoordig vooral geautomatiseerd getest wordt, waarbij de geschreven testen de kwaliteit bepaald wat je vindt.

En de architectuurfout, ben ik ook met je eens, maar vindt maar eens een 30 jaar oude applicatie die geen architectuurproblemen heeft?

[readefries]

Haha, ja daar gaat het mis inderdaad.

Ik denk niet dat die er zijn 🤔

[R4gnax]

Zoals Musk: "Fail fast; fail often"
Het is een bekend Silicon-valley mantra voor experimentele productlijnen en gadgets.
Het heeft geen plek binnen producten die vooral betrouwbaar moeten zijn - zoals een web browser. Maar ja- popie-jopie mening, heh? Dus het kruipt waar het niet gaan moet.

[Reactie gewijzigd door R4gnax op 12 juli 2026 11:21]

[drfisheye]

Want auto's, raketten, satellieten en hersen implantaten hoeven niet betrouwbaar te zijn. /s

[readefries]

Je kan het wel sarcastich noemen, maar je mist het punt helemaal IMHO. Juist doordat het update proces bij autos zo rigide is, rij je jaren met kapotte software. Kijk naar de eerste ID-3's en hor lang het duurdt voordat een fix in je auto zit.

Continous Deployment betekend niet dat je niet test, je test juist veel meer elke keer dat je een release-piepeline aftrapt. En iedere keer voeg je weer iets toe.

Gedurende mijn hele IT-cariëre zie ik het bij klanten of andere bedrijven waar ik werk: veel moeten releasen, wat niet betekend naar een gebruiker over de schutting gooien, verbeterd het product significant.

[RobertMe]

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.

[DonJunior]

... een major (.0) release

bij Semantic versioning is een Major geen (.0) maar (0.) denk dat je hier Minor bedoelde.
https://semver.org/

[Vihaio]

Jawel, als je naar een .0 versie gaat betekent dat dat het nummer ervoor 1 opgehoogd is. x.0.0 is dus altijd een nieuwe major versie

Maar Firefox gebruikt geen semantic versioning. Semver gaat over veranderingen in je api, wat bij een browser niet echt belangrijk is. En Firefox krijgt geen nieuwe versie als er breaking changes zijn, maar als er 4 (of 2) weken voorbij zijn.

[Reactie gewijzigd door Vihaio op 12 juli 2026 11:52]

[Thijzer]

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.

[marc1990]

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)

[willemb2]

Het gaat om een experiment, schrijft een topman van Mozilla.

Waarom post een topman van Mozilla zijn ideeën op een Google forum?

[The_Doman]

Windows 7 ondersteuning toch ook weer verlengd.

https://whattrainisitnow.com/release/?version=esr

We have decided to extend support to ESR 115 only on Windows 7-8.1 and macOS 10.12-10.14 up to March 2027.

[KeiraR]

Ik heb updates dicht staan want ik werd er gek van .
Eens in de zoveel tijd update ik zoals laatst met die hele lijst fixes.

[Martinspire]

Ik vind het prima dat ze veel versies releasen, maar snap niet helemaal waarom het allemaal major versies moeten zijn. Dan haal je het nut van versienummers onderuit en gaan mensen ook met nieuwe releases niet meer kijken wat er nieuw is als zo vaak de veranderingen minimaal of onderhuids zijn.