Software-update: Mozilla Firefox 140.0.2

Mozilla heeft een tweede update voor versie 140 van zijn webbrowser Firefox uitgebracht. In deze uitgave is het onder meer mogelijk om bij verticale tabbladen het aantal permanent zichtbare tabbladen aan te passen. Verder is er ondersteuning toegevoegd voor nog meer zoekmachines, wordt bij een volledige paginavertaling alleen het zichtbare gedeelte vertaald en is het mogelijk het geheugen van een of meerdere tabbladen vrij te geven. Versie 140.0.2 moet een probleem verhelpen onder Windows dat de browser kon doen laten vastlopen.

Fixed

• Fixed a startup crash on Windows experienced by some users. (Bug 1974259)

De volgende downloads zijn beschikbaar:
Mozilla Firefox 140.0.2 voor Windows (Nederlands)
Mozilla Firefox 140.0.2 voor Linux (Nederlands)
Mozilla Firefox 140.0.2 voor macOS (Nederlands)
Mozilla Firefox 140.0.2 voor Windows (Engels)
Mozilla Firefox 140.0.2 voor Linux (Engels)
Mozilla Firefox 140.0.2 voor macOS (Engels)
Mozilla Firefox 140.0.2 voor Windows (Fries)
Mozilla Firefox 140.0.2 voor Linux (Fries)
Mozilla Firefox 140.0.2 voor macOS (Fries)

Versienummer	140.0.2
Releasestatus	Final
Besturingssystemen	Linux, macOS, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11, Windows Server 2022, Windows Server 2025
Website	Mozilla Foundation
Download	https://www.mozilla.org/en-US/firefox/all/#product-desktop-release
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (12)

[Sando]

Na 139.0.0 en 140.0.0 is er nu versie 140.0.2. Vinden we die nieuwe versienummer-hype die Google Chrome is begonnen nog steeds een goed idee?

[eprillios]

Het is niet zozeer een hype die gestart is door Chrome; het heeft ook eigen voordelen. Traditionele versienummering (major versienummers als eerste, minor releases achter punten daarna, wat min of meer een subjectieve afweging is) is niet helemaal gemaakt voor het vaste releaseschema dat tegenwoordig vaak gehanteerd wordt.

Zeker bij webbrowsers is een vaste releasecadans waardevol zodat je per ‘major’ versie een selectie aan nieuwe functies en implementaties van webstandaarden kunt uitrollen, en dit ook makkelijker kunt communiceren aan webdevelopers en testers. Het andere extreme is Internet Explorer versie 6, die een hele lange dienst heeft gehad terwijl vooruitgang achterbleef.

[m-a-r-t-1]

Maar waarom niet een versie nummer gebasseerd op datum aanhouden? Nooit begrepen waarom iedereen dit niet doet. Dus gewoon iets als 20250629_0716.

[beerse]

Naar mijn idee is het 3 tot 5 posities versie nummer het duidelijkste. Daarbij kan positie 3 of 4 als datumveld gebruikt worden. Zie bijvoorbeeld A.B.C.D.E:

A: major versie nummer. Hierbij kan best veel veranderen, tot een compleet nieuwe architectuur toe. Functioneel zal het allemaal wel gelijk/vergelijkbaar zijn maar altijd opletten. De interface kan wezenlijk veranderen en detail functionaliteit kan vervallen.

B: minor versie nummer: Hier tussen is het allemaal altijd gegarandeerd upwards compatibel. Een nieuwere versie is altijd mogelijk. De interface is gelijk behoudens voor de nieuwe functionaliteit. Hier zou ook een match kunnen zijn voor gebruikte protocol versies of andere externe versies.

C: patch versie nummer: Hier zijn de patches voor bugs en andere oeps gevalletjes verbeterd.

D: build versie nummer: Bij het bouwen wordt hier altijd het volgende nieuwe nummer gepakt. Dit zou zomaar doorlopend een oplopend nummer kunnen zijn. Ook kan dit gerelateerd zijn aan het moment van bouwen. Het kan zijn dat verschillende doel-architecturen hier verschillende nummers krijgen.

E: special versie nummer: Een positie om speciale gevallen aan te duiden. Bijvoorbeeld een build voor klanten met speciale wensen.

[dasiro]

zolang er consistentie in blijft en ze niet om de paar jaar van schema veranderen is het nog steeds een goed idee

[lenwar]

Het lijkt er op dat ze semantische versionering gebruiken. https://semver.org/lang/nl/ - Dus dat is een standaardmethodiek.

Uiteraard is dat is onder aan de streep vooral handig voor de ontwikkelaars zelf (en partijen die tegen de software aan (moeten) programmeren. Maar laten we eerlijk zijn. Is een versienummer nu echt zo belangrijk, voor ons als web-klikkers?

[Goderic]

Het versienummer interesseert me helemaal niets, waarom maak jij je er druk om?

[Sando]

De razendsnel oplopende versienummers zijn verwarrend en betekenisloos geworden. Waar een nieuwe major-versie vroeger stond voor een duidelijke sprong in functionaliteit of design, is versie 139.0.0 nu nauwelijks te onderscheiden van 140.0.0. Dit maakt het voor gebruikers en beheerders moeilijk om te zien of er iets drastisch verandert, in positieve of negatieve zin. Denk aan de volledig nieuwe Quantum- en Servo-engine (Firefox 57) of de volledig nieuwe Proton-UI (Firefox 89), gewoon een "incrementje" net als andere nietszeggende kleine updates.

Verwijzen naar "Firefox 89" zegt niks zonder changelog erbij. Anders zouden 89 t/m 140 gewoon "Firefox 4" heten. Deze rücksichtslose always increment tast de betrouwbaarheid van het nummer aan. Een systeem dat ooit bedoeld was om duidelijkheid te geven, levert nu abstractie en desinteresse op. De spronggrootte voelt willekeurig en maakt softwareversies minder menselijk.

offtopic:
/cc @eprillios

[Reactie gewijzigd door Sando op 28 juni 2025 17:20]

[RobertMe]

De spronggrootte voelt willekeurig en maakt softwareversies minder menselijk.

Het is niet willekeurig, elke X weken komt een nieuwe versie uit. En "what's done is done" (en features die niet af zijn schuiven door). Uiteindelijk zijn het allemaal kleine incrementele updates. En de "grote" dingen die jij benoemd zijn wellicht helemaal niet zo groot vanuit development perspectief. Iets als Servo zat of al heel lang er in maar werd maar mondjesmaat gebruikt en steeds uitgebreid in "features" dat het kon, of zat wellicht achter een feature flag. Waarbij bv de eerste code voor Servo al een jaar eerder in een release kon zitten, maar bv nog niet user facing was. Waarbij de door jouw aangehaalde versienummer wellicht puur het aanpassen van een feature flag is. Letterlijk een code change van 1 regel. Maakt dat het dan een major release? Vanuit code perspectief in ieder geval niet. En vanuit gebruikers perspectief maakt Servo vs een andere render engine ook niet uit ("render watte?").

En bij grote projecten wordt het ook steeds lastiger om grote features te onderscheiden. Want elke "grote" feature is bv nog steeds maar 5% van het gehele product. Niet erg veel dus. Dus hoe kwalificeer je dan wat "groot" is?

Zie ook iets als de Linux kernel. Dat was ook jarenlang in een <very major>.<major>.<minor>.<patch>. Totdat er na 2.4 een 2.6 kwam, en er vervolgens geen echt grote wijzigingen meer kwamen die een major version bump verantwoordde. Waardoor 2.6 in december 2003 uit kwam en de laatste, 2.6.39, in mei 2011. Dat is dus 7,5 jaar zonder echt major changes waarbij iemand zoiets had van "dit moet een nieuwe major zijn". Terwijl 2.6 vs 2.6.39 totaal anders zullen zijn, zowel in code onherkenbaar zal zijn. Maar als je ondersteuning voor honderden als niet 1000 apparaten hebt, en nog tich andere kernel features "bestaan" en ontwikkeld worden. Dan is elke X maanden een nieuwe release met bv 10 nieuwe "features" (/drivers of andere zaken) maar een druppel op een gloeiende plaat en niet interessant voor een "nieuwe major". Maar als je over bv een of twee jaar kijkt zie je wel steeds grote veranderingen, maar het is niet dat de ene release substantieel groter is dan de ander en ineens zoveel zaken beslaat dat je zegt "dit is major". En daarom dat Linux uiteindelijk is overgestapt op semi arbitraire major version bumps (terug bij major.minor.patch). Waarbij gewoon echt gekeken wordt naar "de minor versie is nu wel weer wat hoger en de aanstaande release bevat relatief veel code wijzigingen, dus we doen maar weer een major bump". Waarbij er eigenlijk niet wordt gekeken naar de nieuwe features en hoe groot die zijn. Het grootste criteria is "is het nummertje hoog?", en niet "welke features zijn toegevoegd". Simpelweg omdat elke release wel features toevoegt en zaken verwijderd en je niet kunt vastleggen wat "zo groot is" dat het een nieuwe major zou moeten zijn.

[Sando]

Ik ben zelf developer, dus ik ken de argumenten. Veel veranderingen zijn incrementeel en complex. Maar juist daarom is het versienummer er niet alleen voor je teamgenoten maar ook voor de eindgebruiker.

Het oude model (zoals bij Firefox 4 of Red Hat Linux 5) had een belangrijke functie: duidelijkheid. Een major release was een herkenbaar signaal: Dit is anders, dit is nieuw, opletten. Je wist dat er heftige visuele of functionele wijzigingen waren, vaak breaking changes. Dat versienummer communiceerde met mensen, niet met CI pipelines.

Een veel gehoord argument uit die tijd was dat "gebruikers het idee hebben dat development stil staat" en "dat ze minder vaak een patch installeren als het eerste nummer hetzelfde is". Dus ze hebben eigenlijk de build (z in x.y.z) naar voren gehaald om de indruk te geven dat er hard ontwikkeld wordt; ze gaven eigenlijk toe dat ze de gebruiker elke keer willen laten denken dat er een major change is zodat ze de nieuwste versie maar installeren. Het gevolg is dat het versienummer betekenisloos is geworden. Niets meer dan letterlijk een manipulatietechniek. Wij zouden een andere afweging hebben gemaakt. Het is niet erg dat de major versie twee jaar hetzelfde blijft omdat de browser 2 jaar geen grote veranderingen ondergaat. Mensen moeten gewoon altijd updates installeren, en er zijn andere manieren om ze dat te leren.

In plaats van Firefox 4 t/m 57.0.2 had je dan gewoon Firefox 4 t/m 4.53.2.

In plaats van Firefox 58.0.1 t/m 89.0.2 had je dan gewoon Firefox 5.0.1 t/m 5.31.2.

En daarna Firefox 6 in plaats van 140.

En dan nog, als de ontwikkelsnelheid een rol speelt, dan zou een beter alternatief toch een vorm van release date zijn, zoals Ubuntu 24.04.3 als versienummer gebruikt. Dan communiceert het op zijn minst iets. 22.10 en 24.04 zijn ook nogal abstracte nummers, totdat je ziet dat de ene computer een feature freeze uit oktober 2022 draait en de ander één uit april 2024.

[Sjah]

Ik sta achter je Sando.

[Navel Knop]

Mozilla gebruikt dit versie nummering schema in navolging van Google Chrome. Wat versie nummer betreft ligt Firefox voor, Firefox v140, Google Chrome v138.

Even alle gekkigheid terzijde, vroeger waren het grote veranderingen tussen opeenvolgende versies, nu kleinere veranderingen, dus het versie nummer lijdt aan inflatie = is minder waard geworden. Het versie nummer kan me niet echt wat schelen, belangrijker is de functionaliteit en flexibiliteit, soepele werking, zoveel mogelijk bug free (=zonder problemen), en de veiligheid (lieftst geen of anders zo weinig mogelijk veiligheidsrisico's). Firefox is echt flexibeler en echt veiliger mbv NoScript, meer en betere advertentie blokkeer mogelijkheden (Adblockers etc). mbv NoScript kun je b.v. doubleclick blokkeren. Zeker nu Google Chrome is overgestapt op manifest v3 (met veel meer beperkingen) is Google Chrome en afgeleiden een lachtertje geworden op dit gebied.