Mozilla: opgevoerde release-cycle Firefox is goed voor web

Het opgevoerde tempo waarin Firefox-versies worden uitgebracht, is goed voor het web, stelt het hoofd van Mozilla. Bedrijven en ontwikkelaars hadden kritiek op de nieuwe release-cycle; elke zes weken wordt een nieuwe Firefox-versie uitgebracht.

Het hoofd van de Mozilla Foundation, Mitchell Baker, verdedigt de nieuwe release-cyclus van Mozilla's Firefox-webbrowser. Volgens Baker moeten webbrowsers bewegen 'met de snelheid van het internet'. "Als we een browser een interface voor internet willen laten zijn, moet die meer op datzelfde internet lijken", schrijft Baker op haar weblog.

Baker voert aan dat de oude release-cyclus, waarin veel minder vaak nieuwe Firefox-versies werden uitgebracht, ervoor zorgde dat nieuwe functionaliteit pas laat beschikbaar kwam. Soms kwam nieuwe technologie pas na een jaar beschikbaar voor gebruikers en ontwikkelaars, stelt Baker. Het opgevoerde tempo zorgt ervoor dat nieuwe features sneller beschikbaar zijn, aldus topvrouw.

Helemaal ongevoelig voor de kritiek is Baker niet: ze zegt dat het nodig is om 'goed te luisteren' naar mensen die problemen hebben met het nieuwe release-tempo, zoals ontwikkelaars van add-ons en zakelijke gebruikers. Ontwikkelaars hebben nu minder tijd om hun add-ons bij te werken voor nieuwe Firefox-versies, terwijl zakelijke gebruikers minder tijd krijgen om nieuwe versies te testen. Mozilla kreeg vooral veel kritiek omdat het Firefox 4 van slechts één beveiligingsupdate voorzag; daarna werd Firefox 5 alweer uitgebracht.

Onlangs brachten diverse media het nieuws dat Mozilla van plan was om versienummers te schrappen in het about-dialoogvenster van Firefox. Dat lijkt toch niet te gebeuren, meldt ReadWriteWeb nu. Het 'plan' stuitte op veel weerstand, maar volgens de productmanager van Firefox was de beslissing om versienummers te schrappen nog niet eens genomen.

Google Chrome was de webbrowser die de snelle release-cyclus introduceerde: de software, die drie jaar geleden nog niet eens was uitgebracht, is nu alweer bij versie 13. Ter vergelijking: de nieuwste versie van Internet Explorer, die ruim vijf keer zo lang als Google Chrome bestaat, is IE9.

Reacties (100)

[Hakker]

Ik snap niet dat mensen zoveel waarde aan een release nummer hechten. Release nummers hebben geen betekenis en geen vaste definitie. Linux heeft zijn eigen systeem. Google hanteerd meerdere systemen. Microsoft heeft alleen major nummers en voor de rest zijn het invisible fixes die er gedaan wordt. Anderen hanteren weer een eeuwige vorm van beta als je het moet geloven (MAME) andere groepen werken weer met svn nummers, anderen met datum.

Met andere woorden waarom die waarde hechten aan iets wat niet eens vaste regels heeft. Het enige wat een versie aangeeft is dat er iets veranderd is en meer niet.

Helemaal de discussie van ja maar tussen versie 1 en 2 zitten hele grote verschillen. tussen 1.1.x en 1.2.x zitten grote aanpassingen en pas bij de laatste nummering de kleine updates en fixes. Het bestaat niet wat voor hun een grote feature kan zijn hoeft het nog niet eens te zijn voor de gebruiker. Als zij een complete rewrite doen tussen versie 1 en 2 en voor de rest niets toevoegen maakt het voor de gebruiker geen bal uit dus hoe kan je de versie nummering dan ineens verdedigen. Het maakt voor de devs uit de gebruiker niet.

Het bizarre is dat als Firefox het bij de 3.6.x nummer zou blijven houden had niemand er een woord over gezegd en dat stelt uiteindelijk wel vast hoe belachelijk de hele discussie feitelijk is.

[Verwijderd]

Er zijn verschillende zaken van belang bij de versienummers.

Ten eerste zijn er de addons en extensions. Bij een major update van de browser, moeten addons weer opnieuw "compatible" gemaakt worden met de browser. Bij een minor versie wordt er vanuit gegaan dat de API hetzelfde is gebleven en addons blijven werken. Daardoor worden addons dus steeds sneller "oud" en moet je elke keer wachten totdat je addons geüpdate zijn. Zo moest ik met de laatste update een week wachten voordat al m'n addons wilden werken. Versienummers kunnen dus het ontwikkelteam zelf helpen om dit soort zaken in goede banen te lijden.

Verder kan het helpen onderscheiden tussen kleine en grote aanpassingen, wat vooral voor bedrijven van belang is. Zo zouden 5.1, 5.2, etc alleen security fixes kunnen hebben, zodat die versies niet opnieuw getest hoeven worden voor compatibility. Er zijn namelijk geen grote veranderingen. Dan kunnen nieuwe features en andere grotere veranderingen bewaard worden tot major upgrades, zoals 6.0. Dan kan een RC van 6.0 ook getest worden voordat deze gedeployed wordt.

Dat is allemaal een stuk lastiger als er alleen major updates uitkomen, 5, 6, 7, etc.

Edit: ik wil maar zeggen, het gaat niet alleen om het nummertje, maar ook om de development cycle.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 19:51]

[Buggle]

Het punt is vooral dat je versienummer dus geen major update hoeft te zijn, maar het wel kan zijn. Daarnaast kunnen ook securityfixes ingrijpende veranderingen betekenen.

Uiteindelijk is de versienummering niet meer dan een indicatie voor een verandering, en het testtraject moet dan ook nooit een weerspiegeling van het versienummer zijn - het moet een weerspiegeling van de wijzigingen in de software zijn. En die wederom kun je alleen uit de release notes halen; een listing van de exacte wijzigingen. Nogmaals; het versienummer is alleen een indicatie, een soort samenvatting. Het heeft dan ook inhoudelijk gezien geen gevolgen voor je testtraject.

Het enige wat dus nu verandert is dat je nu aandachtiger het ontwikkeltraject van FF moet bijhouden om te kunnen bepalen hoe 'major' de update eigenlijk is. Dat moest je toch al, om het testtraject te kunnen bepalen.

In feite betekent dit dus dat de bedrijven naar de efficientie van hun testtrajecten moeten gaan kijken: het testtraject kan nu groter of kleiner zijn afhankelijk van de inhoudelijke wijzigingen in het bewuste programma. Het heeft geen zin om groot te gaan zitten testen als je toch weet dat er geen wijzigingen zijn in de delen van je browser die van belang zijn voor je bedrijfsproces. Dat vergt misschien wat aanpassing, maar uiteindelijk verhoogt het ook bij het bedrijf de efficientie.

Edit: waar je overigens een terecht punt zou hebben is de instabiliteit van de API voor de extensies. Het zou niet mogen gebeuren dat het wel of niet werken van een extensie bij een update niet te voorspellen is; dat betekent dat de API aangepast is, of een extensie buiten de API om allemaal hippe dingen aan het doen is. Aan de andere kant is dat ook weer een kracht van FF, aangezien extensies als NoScript en AdBlock diep in de browser kunnen ingrijpen en dus voordat de pagina laadt al zaken beinvloeden. Bij Chrome, waar de plugins minder diep zitten (en dus ook niet constant breken), is de functionaliteit van genoemde plugins een stuk minder effectief. In de praktijk betekent het gebruik van bijv. AdBlock in FF dat je minder dataverkeer hebt (de reclame wordt niet eens opgehaald), waar bij Google precies hetzelfde dataverkeer plaats vindt, maar de reclame alleen niet weergegeven wordt.

[Reactie gewijzigd door Buggle op 24 juli 2024 19:51]

[BikkelZ]

Ik hoor alleen mensen klagen over brekende extensions. Wellicht dat het een goed idee is om de extension API apart te versionen van de browser zelf? Volgens mij gebeuren er namelijk niet zulke hele spannende dingen op dat gebied namelijk per release. Niet iets wat een brekende extensions zou moeten veroorzaken iig.

[Nakebod]

Sterker nog, bij Chrome heb ik nog nooit een niet werkende extension gehad omdat Chrome zichzef had geupdate.
En dat was ook met extensions waarvan ik zeker weet dat die niet contant up2date werden gehouden "aan de hand van de Chrome versie". Sterker nog, kan best dat 1 extentie al 2 jaar niet meer geupdate is en nog steeds prima werkt.

Dus in theorie moet Firefox dat natuurlijk ook kunnen.
Als ze dan ook nog eens die irritante restart @ extensie installatie/update eruit slopen zijn er heel veel mensen blij.

[Lennie]

Zo'n API bestaat al jaren, alleen is die API dus pas een 'paar' jaar oud. Dus oude addons gebruiken die API (nog) niet.

Nieuwe extenties, als hun auteur slim is gebruikt gewoon de nieuwe API.

Tevens bijna alle addons op de https://addons.mozilla.org/ website worden voor iedere release automatisch al getest en het versie-nummer bijgewerkt en de auteur ingelicht.

(addons zonder source kunnen natuurlijk niet automatisch gecontroleerd worden vermoed ik)

Het zijn vooral de addons die niet op de https://addons.mozilla.org/ website staan die kapot gaan, vaak worden die meede daardoor slecht onderhouden.

[sirono]

kijk, dat is nog eens een goed idee!
en als ze dat nu gelijk doorvoeren voor andere producten (thunderbird).

misschien kunnen ze het zelfs zo maken dat de developer de api versie kan kiezen.
dan heb je nooit meer incompatiblity. alleen zit je dan met dingen die misschien niet meer mogelijk zijn... maar er zijn vast mensen die daar goed over na kunnen denken

edit:
ik heb ook wel eens iemand horen opperen om een ubuntu release schedule aan te houden.
dus versie 4 die bijvoorbeeld 2 jaar ge support wordt.
en tussendoor snelle updates.

[Reactie gewijzigd door sirono op 24 juli 2024 19:51]

[Tom]

Bij Firefox 3.x hadden ze een dipje, het duurde wel erg lang voordat FF4 uit kwam en ze begonnen achter te lopen op de concurrentie. Daar zal men voor willen waken... er is altijd wat te verbeteren maar op een gegeven moment zul je toch de boel moeten releasen. Dan spreekt de nieuwe release-cycle mij meer aan... vaker kleinere updates uitbrengen. Hetzelfde als Chrome doet.

Voor de gebruiker maakt het ook weinig uit, het updaten gaat nagenoeg onopgemerkt. Dat versienummers niet meer de opbouw hebben als vroeger is jammer, maar tijden veranderen. Wat mij betreft volgt IE ook, vaker nieuwe versies en een auto-updater. Het lost het kip-ei probleem op waar webdevelopers altijd tegenaan liepen. Zo kunnen we (werk als webdesigner) ook meer innoveren.

[joostvanpinxten]

Chrome wordt inderdaad automatisch geupdate, waardoor men de laatste browserversie over het algemeen wel geïnstalleerd heeft. Echter, ben ik het ook niet helemaal eens met de release versies.

De manier waarop FF bezig was, was te traag: te weinig releases, maar elke release was wel betekenisvol. Nu is elk muggenzifterij een major release, terwijl dit in de klassieke software engineering betekent dat er een flinke slag in ofwel de performance ofwel functionaliteit is gedaan; een merkbaar groot verschil in code in ieder geval.

Voor ondersteuning wordt er regelmatig gekeken naar het releasenummer en in het geval van een major release wordt er een complete andere test-cycle doorlopen. Dit komt omdat er grote wijzigingen verwacht worden. Het probleem is dus niet zozeer dat de releases zich zeer snel opvolgen, maar vooral dat de interpretatie van de releasenummers veranderd is. En in het geval van FF is dat wel heel extreem veranderd.

[Tom]

Wat mij betreft stappen we van die klassieke versienummers af. Er zijn ook steeds meer webapplicaties die continu geüpdatet worden. Zeker als men werkt met een Agile-ontwikkelmethode. Het heeft allemaal z'n voor- en nadelen, maar voor de gebruiker zie ik vooral voordelen. Een jaar of meer aan een major-release werken vind ik wat ouderwets, het hoeft allemaal niet meer op een cdtje gedrukt te worden.

[Lennie]

Als je denkt dat er een heel strak wordt omgegaan met minor release en een major release, dan ben je toch al naief.

[wildpicture]

Het is heel simpel. Microsoft is met IE bij versie 9. Veel simpele gebruikers redeneren dat een versie 9 nieuwer en dus "beter" is dan een versie 5 of 6. Firefox wil daarom zo snel mogelijk ook een serienummer dat gelijk is aan dat van Microsoft.

[Toolskyn]

De nieuwe versienummers zijn puur en alleen gebaseerd op het nieuwe ontwikkeltraject (wat dan wel erg veel weg heeft van het Chromium/Chrome ontwikkeltraject). Met het snel ophogen van versienummers heeft het eigenlijk weinig te maken. De meeste ontwikkelaars willen sowieso af van dat gedoe van versienummers. Voor gebruikers zou het versienummer helemaal niet interessant moeten zijn is de redenering, het gaat uiteindelijk om de software die je gebruikt.

[Verwijderd]

FF is gigantisch groot geworden met versie nummers die altijd achterlagen op IE en is pas gaan verliezen toen chrome kwam
Ze denken misschien dat de snelle chrome versie het succes bepalen maar het is eerder de enorme hoeveelheid promotie die Google er tegenaan gooit die Chrome zo vooruit stuwt tov Firefox
Zo wordt zelfs de heilige Google frontpage waar nooit reclame op stond nu misbruikt voor Chrome promotie.

[dj.verhulst]

en allerlei applicaties stellen voor om chrome te installeren,
hoe vaak ik wel niet eindgebruikers aan de telefoon gehad heb die ineens chrome voor de kiezen kregen en dat niet wilde als ze een op een url klikte ipv hun ff......

[Lennie]

Onzin.

[poepkop]

Tja, zijn argumenten blijven vaag... Want ik zie nergens waarom het dermate snel ophogen van een versienummer i.p.v. een subversie goed zou moeten zijn...

Aan de andere kant: Ik kan nu wel tegen iemand zeggen met versie 3.5 al een 'zwaar verouderde versie' heeft, wat handig is als een leek weer eens anti-update is.

[mokkol]

Dit dus. Ik snap nu niet waarom het nu 3 cijferig is. Dit middelste blijft gewoon nu altijd op 0 staan.

Waarom niet gewoon zo met de nieuwe cyclus:

4.0
4.1 => security fix
5.0
5.1 => security fix
5.2 => security fix
6.0
etc etc

ipv

4.0.0
4.0.1
5.0.0

persoonlijk snap ik het helemaal niet ... wat is er nou zo erg aan een 4.5 versie. Waarom moet dat nou persee versie 9 zijn? Zo krijgt het versie nummer totaal geen identiteit. En wat als ze een keer de api drasitsch veranderen? Dat is normaal een major release, maar nu is dat precies hetzelfde soort release als elk ander update. Versie nummers hebben nu totaal geen identiteit meer. Je kan beter de datum nemen als versienummer ofzo....

[ReLexEd]

Je slaat de spijker bijna op de kop, en toch volledig mis....

Zo krijgt het versie nummer totaal geen identiteit.

Precies... en zo hoort dat ook (imho)....

Een versienummer id geen identiteit, daarom is het ook een nummer...

Jij gaat toch ook door het (tweakers)leven als Mokkol en niet als 270746.....

Een versie nummer is niets meer dan een etiketje dat aangeeft in welke rangorde de release zit.....
Dat bedrijven er nu een rare smaak van in de bek krijgen als ze een security-update als een .x of zelfs een .x.x vrijgeven en daarom een X.0 uitgeven... tsjah....

Het blijft dezelfde functionaliteit....

Dat het voor de ontwikkelaars daar nu betekent dat ze een nieuwe geimplementeerde technologie na 6 weken maximaal kunnen opleveren is mooi, maar weegt niet op tegen de problemen die ze de gebruikers (zeker op zakelijk vlak) meegeven....

Neem een groot bedrijf waar ze weken nodig hebben om een nieuwe versie te testen voordat deze uberhaupt mag worden uitgerold... Stel dat die 2 weken voor een test nodig hebben, en nog een week voor de uitrol...
Die hebben als ze bij willen blijven dus na de uitrol van FF6 3 weken weer een project op stapel staan genaamd FF7.... hoe denk je dat de heren directeuren bij zo'n bedrijf daarop reageren?

Weet je wat... die IE9 doet het prima, en is proven technology.. we houden het daar wel bij.... (want daar komen we security-patches voor uit, die een stuk makkelijker te valideren zijn)....

[dotnetpower]

Ze zouden voor die zakelijke gebruikers gewoon om de X releases een LTS versie moeten uitbrengen, nu drijven ze bedrijven weer richting Internet Explorer of Opera.

Nu Internet Explorer weer sterk afhankelijk is van het OS (IE9 enkel op Vista / Windows 7 en IE10 enkel op Win 7 etc..), krijgen we over X jaar dat we als webdevelopers weer moeten gaan testen of ontwikkelen op oude versies (alhoewel dit veel minder problemen zal gaan geven dan tussen IE6 / IE7 en IE8 releases momenteel).

[Verwijderd]

Ik snap niet echt waarom ze belangrijke security fixes niet gewoon backporten of patchen in oudere versies. Als ze elke keer de vorige versie niet meer supporten, dan is het inderdaad erg onhandig voor het uitrollen binnen bedrijven. Deploy je nu een versie van Firefox, komt over 6 weken een nieuwe met belangrijke security fixes, kan je weer opnieuw beginnen met testen en uitrollen. In plaats van kleine security fixes die weinig impact hebben en dus niet expliciet getest moeten worden.

Misschien moeten ze Firefox maar eens gewoon helemaal uit elkaar slopen. Eigenlijk waren ze daar vroeger al mee begonnen. De Mozilla Suite bestond, met allerlei programma's met een heleboel features. Toen werd de basis van de browser eruit gehaald en op de markt gezet als Firefox. Sindsdien is Firefox eigenlijk alleen maar weer gegroeid en heeft het allerlei onzinne features en gedoe, die ook makkelijk in addons gezet hadden kunnen worden.

Als ze nou de browser zo ontleden dat de basis van de browser los ontwikkeld wordt van features, dan kan de browser dus elke keer minor security fixes krijgen zonder dat dat grote impact heeft op het geheel. Dan is het voor bedrijven aantrekkelijk om Firefox te gebruiken, omdat ze dan onbezorgd security fixes kunnen installeren. En ook voor consumenten blijft dan de release cycle bestaan als die ze nu geïntroduceert hebben, omdat de nieuwe features en dergelijke gewoon losse componenten zijn (addons dus eigenlijk) en apart geüpdate kunnen worden.

Heel handig en iedereen blij!

/me droomt lekker verder.

[Verwijderd]

En wat als ze een keer de api drasitsch veranderen? Dat is normaal een major release, maar nu is dat precies hetzelfde soort release als elk ander update.

daar gaat het hem juist om, er komen NOOIT meer drastische veranderingen maar alleen nog maar 'kleine' veranderingen die samen wel drastisch worden. Daarom zijn alle toekomstige updates óf allemaal major óf allemaal minor. Nu zouden ze wel het bij 4.x hebben kunnen laten, maar dan zouden we voor eeuwig aan 4. voor het getal zitten wat eigenlijk niets meer zou zeggen. dus waarom dan dat 4. niet gewoon weg laten? en om verwarring te voorkomen beginnen we dan meteen met 5 en kijk, daar hebben we de huidige nummering. persoonlijk ben ik blij dat ze gewoon straks aan verzie 33.0.1 zitten ipv aan versie 4.26.0.1 omdat die laatste alleen maar weer langer is en alleen maar irritanter is om te lezen. En als ik kijk naar alle geweldige features die er aan komen ben ik dankbaar dat het voortaan zo snel gaat

[mokkol]

Er komen wel grote features bij. Die worden nu alleen binnen 6 weken erin gezet ipv wachten tot de nieuwe final. Maar zoals ik al zei, het probleem is nu dat een versie geen identiteit meer heeft. Een bedrijf weet nu gewoon niet wanneer ze even goed moeten testen. Ze moeten nu constant testen, wat ze natuurlijk niet gaan doen.

[Reactie gewijzigd door mokkol op 24 juli 2024 19:51]

[Buggle]

Ja, of ze worden nu gedwongen de release notes nog beter door te nemen en dus ook beter te begrijpen wat er exact aan de browser verandert. Ergo: het testtraject moet nu op de releasenotes gebaseerd worden in plaats van op een indirecte manier via de versienummering. Het kost meer tijd, dat wel, maar misschien dat het op den duur leidt tot een betere feeling met de techniek achter de browser. Je bent nu als admin/developer gedwongen gedurende de ontwikkeling bij te houden wat er allemaal met FF gebeurt - dat betekent wat mij betreft vooral een andere houding voor de gebruiker van FF, zij het een developer, gewone gebruiker of sysadmin. Ik zou niet willen zeggen dat dat per definitie sleccht is.

[Finraziel]

Dat werkt maar eventjes... Nu is dat verschil tussen 3.5 en 6 of 7, dat klinkt wel indrukwekkend. Over een paar jaar wordt het het verschil tussen 35 en 38 of 39 en dan ben je weer terug bij af.

[Lennie]

Het zijn _haar_ argumenten trouwens. Niet _zijn_ argumenten, maar dat is maar een klein detail ;-)

Willekeurige introductie die ik vond via Google:

http://www.youtube.com/watch?v=5ZGDjTlf434

[Deem]

Ik vind het echt onzinnig. Wat vroeger een minor release was is nu op eens een major release. Ik zie het verschil niet met hoe het voor de opgevoerde release-cycle er aan toe ging.

[RMX]

Het slaat ook nergens op. Addons zijn ineens niet meer toegankelijk, omdat de maker handmatig het versienummer moet bijwerken.
Een wasseneus als je het mij vraagt.

[Chris7]

Ja, maar met bijvoorbeeld de Add-on Compatibility Reporter kun je add-ons dan alsnog draaien.

Mozilla kreeg vooral veel kritiek omdat het Firefox 4 van slechts één beveiligingsupdate voorzag; daarna werd Firefox 5 alweer uitgebracht.

Dat is dus niet helemaal juist: Firefox 5 was zélf een update voor Firefox 4. Firefox-releases zijn nu niets meer dan updates voor voorgaande versies.
En ik ben het helemaal met Mozilla eens: Features komen nu veel sneller in Firefox terecht dan normaal. Op hun wiki is het goed te zien: Als een feature een release niet haalt, schuift hij eenvoudigweg door naar de volgende versie. Daar zie je bijvoorbeeld dat Firefox 9 een heleboel nieuwe features heeft, terwijl Firefox 7 er veel minder heeft. Blijkbaar konden ze die features dus niet op tijd af maken.

En als gebruiker profiteer je: Als een developer nét een release niet haalt, komt die over 6 weken toch al in Firefox. Als een feature net niet in Firefox 3.6 was gekomen, moesten gebruikers 1,5 jaar wachten totdat ze deze in Firefox 4 konden gebruiken. Dus dit is veel beter.

[Reactie gewijzigd door Chris7 op 24 juli 2024 19:51]

[F.West98]

Vroeger waren versienummerupdates grote updates, met verandering van uiterlijk. FF3 was heel anders dan 2, en 4 ook compleet anders qua indeling en uiterlijk. FF3.1 en 3.6 hebben andere functies. Gelijkwaardige toevoegingen als in Firefox 7 tov FF6 waren er ook tussen 3.1 en 3.6. Want voor de algemene gebruiker verandert er niets. Ik ZIE het verschil tussen FF5 en FF6 niet direct. Tussen 3 en 4 zeker wel.

Ik vond het oude beter:
x.x.xxx
major nummer: geeft aan normale gebruiker aan welke look ed, bij ophoging drastische veranderingen
subnummer: geeft info over features, zoals de eigenlijke verschillen tussen 5 en 6
subsubnummer: geeft info over versie qua beveiliging

Als ze nou elke 6 weken subnummer ophogen met wat nieuwe functies, en dan na 9 maanden stoppen, en dan na 3 maanden met een nieuwe major komen die veel updates bevat, ook qua uiterlijk. En tussen elke 6 weken ook kleine minor fixes doorvoeren is het makkelijker.
Je hebt duidelijk een beta van een nieuwe versie, en niet een beta van versie 10 waar je nu op 6 zit....

De oude cycle was beter... Tweakers gaat elke fix aan pw ook niet pw 4 en pw 5 noemen?

[Lennie]

Wat maakt het uit ?

Wat ze vooral willen is een nieuwe versie uitbrengen die ook een nieuwe API heeft.

Dus als iedere subnummer release betekend dat alle extensies daar kort voor getest moeten worden, etc. zoals nu met de major nummers dan is er dus geen verschil met nu.

Anders dan het nummer.

[bigbadbull]

Ja maar dat kan net zo goed met minor releases.
En de Major releases gebruikt als er grote applicatie veranderingen kunnen verwachten.
Een extra feature als je URL veranderd van kleur geeft geen impact naar andere applicaties.

Een security check veel meer.

[mcDavid]

Als je wilt weten wat er veranderd is tussen twee versies, kun je beter de release notes eens doorlezen, er verandert namelijk meer dan alleen wat je op je scherm kunt zien.

[-Colossalman-]

Ik denk dat je het niet meer als minor of major release moet zien.
Het zijn gewoon nieuwe releases met of zonder nieuwe grote functionaliteiten.
Ik ben zelf ook (nog) niet zo'n voorstander van deze snelle release cyclus, maar misschien veranderd dat nog. De tijd zal het leren.

[Verwijderd]

Dat is dus niet waar, zie het verhaal hierboven. Er zijn in feite geen minor releases meer.

Als een grote feature is af op een development branch kan die gemerged worden met de release versie. Grote wijzigingen werden allen doorgevoerd in major releases en als je dus pech had moest je lang wachten voor iets wat klaar was al beschikbaar was. Om die reden heb ik lange tijd met nightly builds gewerkt.

Nu kan een grote feature als die klaar is iedere zes weken geïntegreerd worden met de release versie en hoef je dus nooit langer dan zes weken te wachten op iets dat af is.

Er is dus geen onderscheid meer tussen major en minor releases. Hoogstens nog tussen releases en bugfixes.

[Antipater]

Ik vind het echt onzinnig. Wat vroeger een minor release was is nu op eens een major release. Ik zie het verschil niet met hoe het voor de opgevoerde release-cycle er aan toe ging.

Dat is niet helemaal waar. Als Mozilla op de oude voet was doorgegaan, dan hadden we nu 4.2 of zoiets gehad zonder een aantal zaken die nu in 6 zitten. Die zouden dan nog een jaar voorbehouden zijn aan de ontwikkelversie.

[wdvjb]

Volgens mij slaat het wel degelijk ergens op en is zo'n opgevoerde release-cycle daadwerkelijk een ander verhaal dan eens in de anderhalf a twee jaar een grote release.

Wat nu gebeurt is dat de browser steeds kleine incrementele verbeteringen krijgt. Net als de linux kernel. Op die manier hoef je niet twee jaar te wachten op nieuwe features die nu al de browse ervaring zouden kunnen verbeteren. Ook worden de features veel beter getest en kunnen eventuele beveiligingsproblemen makkelijker gevonden worden

Een lange release cycle spaart alle nieuwe features twee jaar lang op en stort ze dan in een keer de wereld in. Op die manier moet al het testen door de community veel gehaaster gebeuren . Als bepaalde features problemen veroorzaken is dat lastiger te vinden.

[Kawaii]

Het kost toch nog steeds evenveel tijd om een bepaalde feature te ontwikkelen? Dus als het nu een jaar kost, dan kost het met de nieuwe release cycle toch ook een jaar? Kleine/simpele features zullen uiteraard sneller doorgevoerd kunnen worden, maar kleine features werden voor zover ik weet ook al in de minor releases opgenomen.

Sinds v5 ben ik wel weer erg over firefox te spreken, alleen de (schijnbare) incompatibiliteit van verscheidene add-ons is nog wel eens vervelend.

[Reactie gewijzigd door Kawaii op 24 juli 2024 19:51]

[IJsbeer]

Als je een grote feature hebt ontwikkeld mag dat alleen gereleased worden in een major update. Je kan niet in een x.x.1 release ineeens nieuwe functionaliteit zetten. Tussen release 3 en 4 zit bijvoorbeeld een jaar, en als je functionaliteit nog niet (stabiel) genoeg had terwijl de code freeze van 3 al voorbij is, is de volgende kans dus pas volgend jaar.

Met de huidige release heb je 'hooguit' 6 weken vertraging.

[Niemand_Anders]

Maar waarom zou je per se aan major update cycles van een jaar willen vast houden. Als de super grote wijziging klaar is, is hij klaar en kun je gewoon het major versie nummer ophogen. Daar zit het probleem niet.

Sinds kort is FF6 uit. MeasureIt is nog niet bijgewerkt en dus niet beschikbaar, maar is
hier wel een requirement. Hetzelfde geld voor IETab. Firefor is sinds vorige maand ook van alle PC's verwijderd en overal staat nu Opera en Safari. Zelfs MSIE begint gewoon weer aan populariteit te winnen.

Echter een hoge release cycle staat niet gelijk aan het snel ophogen van je versienummers. Een update voor Firefox 3.6.x kunnen wij in een paar uur testen. De testcase voor een minor update neemt al een dag in beslag en de test suite voor een major update komt neer op een week testen. En pas als alle extensies werken op de nieuwe versie accepteren wij de nieuwe versie en zetten wij de versie (en updates van extensies) klaar voor deployment.

Het feit dat Mozilla nu eigenlijk gewoon toegeeft gewoon niet naar zijn eigen developers te luisteren is al een doodzonde, maar ook nog eens de totale zakelijke markt negeren is al helemaal niet verstandig. Mozilla is heel erg hard bezig uit de gratie te raken bij een hele grote groep aanhangers welke het vaak voor Firefox hebben opgenomen.

Gebruikers kiezen een browser omdat deze het meest aansluit bij hun eisen, niet omdat een browser het hoogste versienummer heeft van alle browsers. En daarbij kan IE9 niet zoveel minder dan Chrome, maar kan MSIE bij bedrijven in alle facetten op 'afstand' worden beheerd in de vorm van policies.

[elteck]

Je zit hier wel met een conflict. Want hij ziet het heel goed, de snelheid waarmee het internet aan veranderen is, neemt toe: "cloud computing" groeit ondanks of dankzij de crisis erg hard: http://www.siia.net/blog/...-growth-and-job-creation/, mobiel internet staat nog in de kinderschoenen en gaat straks ook de auto in en de medische wereld veranderen (ben ikzelf mee bezig ), en de devices waarop de browser moet draaien veranderen snel. Dus ja, wil de webbrowser niet straks door allerlij specialistische apps in een hoek gedrukt worden, maar zelf het platform blijven, moeten ze voorop lopen.

Aan de andere kant heb je een probleem met de zakelijke markt, die zo conservatief is als de vliegtuig industrie. Betrouwbaarheid voor alles. Kun je die twee belangen verenigen? Mischien de Redhad benadering van Fedora voor "bleeding edge" en Redhat voor de zakelijke gebruiker o.i.d.?

Daarnaast denk ik dat de zakelijke klanten zelf een probleem hebben. Zeker in deze crisis tijd, waarbij veel IT afdelingen met minimale bezetting draaien, zie je dat veel bedrijven eigenlijk onverantwoord traag hun systemen updaten. Nog steeds draaien er veel op Windows XP, wat zo langzamerhand wel een museumstuk genoemd mag worden. Maar ook het uitrollen van security patches gaat onverantwoord traag, als je kijkt naar de snelle groei in "cyber crime".

[divvid]

Mischien de Redhad benadering van Fedora voor "bleeding edge" en Redhat voor de zakelijke gebruiker

Vandaar dat we als semi-zakelijke gebruiker nu rap aan het overstappen zijn op de Ubuntu-LTS versies (vanaf 4/2012 weer). Simpel weg omdat de 'gebruiker' (i.o.g. programmeurs tegen problemen aan loopt met die 'oudere' versies van RH

[humbug]

Een lts versie is in feite hetzelfde als een rhel versie. Linux met langere tijd ondersteuning. Waarbij ubuntu gratis is maar of je voor die paar honderd euro per jaar red hat moet afschrijven? Je hebt als bedrijf wel grotere kostenposten.

[Sjah]

Goed verhaal.


quote: Mozilla is heel erg hard bezig uit de gratie te raken bij een hele grote groep aanhangers welke het vaak voor Firefox hebben opgenomen.

Ook dat is waar, maar lopen ze en masse weg? Gelukkig niet, waar moeten ze heen. Een algehele IE-afkeer hoort beetje bij hen. Hou je Chrome over, dat lijkt veel op waar Firefox heengaat, dat is het ook niet helemaal. Opera dan? Voor sommigen jah, niet voor velen.

[ikweethetbeter]

Ik gebruik FF nog omdat ik niet van de oneindige informatie vergaring van Chrome houd. Op het web ben je niet anoniem, maar met Chrome laat je helemaal overal (vooral bij Google) je sporen achter.

Maar als FF zo doorgaat, komt er een keer een tijd dat ik liever mijn laatste stukje privacy opgeef en voor Chrome kies. Na elke zinloze update (van FF4 naar FF5 en van FF5 naar FF6) raak ik plug-ins en instellingen kwijt. Ik krijg bv mijn knoppenbalk en tab balk niet zoals ik dat zou willen. Waardeloos!

[cyberstalker]

Dan kun je natuurlijk nog altijd Chromium gebruiken. Zelfde engine, open-source, zonder de informatie honger van Chrome.

[Lennie]

Dat is natuurlijk onzin, hier al 2 voorbeelden:
1. Chromium heeft een combineerde search- en adres-balk dus zelfs als je webadres-waar-ik-liever-niet-mee-geassocieerd-wil-worden intype in de adres balk wordt dat naar Google gestuurd.

2. want zoals in het verleden al is gebleken dat een bug in een klein hoekje zit en dat al maanden informatie gekoppeld kon worden door Google over het Chromium-ID en de Google.com-cookie. Foutje, bedankt.

Geen interresse.

[Zunflappie]

Waarom niet de overstap naar Opera?
Die staat nu op 11.50 en gaat binnenkort naar 12.00
Ik weet de precieze cycli niet, maar die is ook geen jaar.

Integratie en updaten gaat geruisloos en heb nooit problemen gehad. Maar ik ben ook maar een 'gemiddelde' browser.
En nog steeds wordt Opera niet volledig ondersteund (of ondersteund Opera niet volledig).

DigID werkt wel op IE en FF, niet op Opera.

[Verwijderd]

Ik vind dit dus raar, een release nummer is toch vrijwel niks meer als een abstracte manier om de veranderingen bij te houden, moeten grote features dan per se dan met een nieuw nummer komen? Zijn we dan over een jaar niet al bij Firefox 16 of iets dergelijks zijn?

Kan je net zo goed Firefox 4.16 hanteren of iets dergelijks.

[Azzmodan]

Dit is niet helemaal waar, Firefox had altijd al dat sommige van de "minor releases" ook vrij grote aanpassingen hadden.

In de praktijk is er dus niet heel veel veranderd door de nieuwe manier van versie nummers geven, maar de snellere releases zorgen er wel voor dat losse functionaliteit

[Verwijderd]

... ?

[koter84]

welke major updates waren er dan van v4 naar v5 en van v5 naar v6 ?????

[cyberstalker]

De tijd die het kost om een nieuwe feature te implementeren is met deze versnelde releases inderdaad niet aangepast.

Het verschil is dat wanneer een bepaalde feature vlak na een release in de ontwikkelversie van Fx werd geimplementeerd het daarna lang duurde voordat deze versie in een stabiele versie naar buiten werd gebracht (en dus beschikbaar werd voor het grote publiek).

Wanneer nu een feature aan de ontwikkelversie wordt toegevoegd duurt het maximaal zes weken voordat deze in een stabiele versie zit.

[Lennie]

Wanneer nu een feature aan de ontwikkelversie wordt toegevoegd duurt het maximaal zes weken voordat deze in een stabiele versie zit.

Nadat de feature klaar is. Er zijn natuurlijk stapels features die in de development versies zitten die nog lang niet klaar zijn.

[braaibander]

Dit is zeker niet waar.
Natuurlijk zullen features die een jaar kosten om te ontwikkelen nog steeds een jaar blijven kosten, maar dit zijn major features waarvoor je gewoon een major release wil maken. In de tussentijd ben je nog bezig met een heleboel andere features. Als je met die kleinere versies moet wachten tot een major release zou het betekenen dat deze moeten wachten op de eerstvolgende release. Je wil namelijk zo min mogelijk versies uitbrengen op elke major release, bugfixes en security fixes zullen wel snel doorgevoerd worden natuurlijk.

Daar bovenop is er een groter risico. Hoe meer features je in 1 release zet, des te meer bugs er (kunnen) ontstaan. Wanneer je deze meer gefaseerd uitbrengt zul je simpelweg minder bugs vinden. (Het bedrijf waar ik werk heeft begin van dit jaar ook een versnelde release schedule aangenomen, en ik heb dit verschil first hand meegemaakt)

[humbug]

Je vindt minder bugs per release maar programmeurs gaan niet opeens beter programmeren. Het aantal bugs blijft dus gelijk.

[Verwijderd]

Binnen Banken geld een test en release procedure van gemiddeld 5 tot 6 maanden, in die tijd zit je dus 4 versies verder van Firefox. Dit gaat deze bedrijven nooit bijhouden en drijft ze rechtstreeks in de handen van IE. Dit terwijl ik voor prive en zakelijk gebruik firefox prevereer. Juist die add-ons van Firefox zijn datgene wat het beter maakt dan andere browsers voor mij, als dat om zeep geholpen gaat worden dan is Chrome het enige echte IE alternatief, dat was naar ik begreep toch al sneller.

[BikkelZ]

Testen banken ook iedere virusscanner update 5 tot 6 maanden? Iedere critical patch voor Windows? Uiteindelijk gaat het er om of je intranet applicaties niet breken, daar kun je best wel een oudere browser voor laten staan.

Intranet legacy crap -> IE6
Internet -> FF, Chrome.

Je pleurt bij Henk en Mien gewoon een paar shortcuts op hun bureaublad waarmee ze legacy apps opstarten, die starten nog IE6 op, en een shiny button voor Internet, waarmee een echte browser opgestart wordt.

[SirBlade]

Ja, banken testen alles grondig, al is voor een simpele bugfix minder tijd nodig dan voor een nieuwe versie.

Dat betekend dat je 2 applicaties moet supporten ipv 1, dus dubbele kosten, plus het risico dat dat iemand de verkeerde browser gebruikt en er iets mis gaat binnen zo'n legacy-app. Waarom zou een bedrijf die kosten en dat risico nemen? Weinig tot geen business-relefante websites vereisen nieuwe technieken, (kip/ei-scenario). Kunnen de werknemers niet meer van facebook of gmail gebruik maken? Nou en, dat hebben de meesten toch niet nodig voor hun werk.

[BikkelZ]

Je bedoelt dat mensen onverhoopt met IE6 op een malware infested site terecht komen (bijvoorbeeld omdat de Joomla!-site van hun voetbalclub gehackt was) nu gelijk volop geëxploiteerd kunnen worden omdat een systeembeheerder het te veel werk vindt om een veel veiligere nieuwe browser te testen?

Een browser is gewoon veel te belangrijk om géén security-patches te laten toepassen.

[Rolfie]

neen, je bedrijfs applicaties moeten goed draaien. Das belangrijker dan de laatste patches draaien. Securlty kan je op verschillende manieren goed regelen.

Internet Sites kan je op een andere manier regelen.
bv Proxy Server al dan niet icm AntiVirus en toegangs controle.
Waarom moet je voetbal club web site op je werk checken?

[Lennie]

Iedere virus-scanner update ?

Die hebben kunnen namelijk misschien nog wel de meest verstrekkende gevolgen, naast een operating system update, hebben van alle software die op een computer staat.

[ZpAz]

Chrome heeft dezelfde snelle versienummer ophoog tempo.

[BonzO]

Het lijkt erop dat veel mensen gewoon bang zijn voor verandering, bij Chrome is dit tempo (vrijwel) altijd al geweest en dat wordt geaccepteerd door de meeste mensen. Nu hanteert FF hetzelfde systeem, wat drastisch verschilt van "oude" systeem, en iedereen loopt te klagen.

Mensen geven alleen maar tegenargumenten dat het slecht is voor eindgebruiker, maar het is juist goed dat er wordt vastgehouden aan een cyclus van een release eens in de 6 weken. Aangezien de code ervan profiteert, developers worden namelijk verplicht kleinere delen te pushen/commiten, wat vervolgens resulteert in andere developers die deze code ook "binnenhalen" en reviewen/testen. In andere woorden: het is zeer waarschijnlijk dat meer mensen bepaalde stukken code gezien hebben voordat een release uitkomt.

Ik geef toe, dit kan ook met een "minor-release" systeem, alleen is de "drang" als developer dan ook groter om een bepaalde functionaliteit in die minor release te krijgen?

[goeroeboeroe]

Het lijkt erop dat veel mensen gewoon bang zijn voor verandering, bij Chrome is dit tempo (vrijwel) altijd al geweest en dat wordt geaccepteerd door de meeste mensen. Nu hanteert FF hetzelfde systeem, wat drastisch verschilt van "oude" systeem, en iedereen loopt te klagen.

Voor mij geldt dat in ieder geval niet, en ik denk voor heel veel mensen niet.
De nummering zal mij persoonlijk volledig worst zijn. Desnoods gaan ze met tientallen gelijk omhoog.
Het voornaamste probleem is dat veel extensies/add-ons niet meer werken, keer op keer. En dat heeft rechtstreeks met die nummering te maken.
Bij Chrome speelt dat probleem niet.
Dat heeft dus helemaal niets met verandering te maken. Ik ben momenteel bij elke nieuwe versie ongeveer 'n volle dag bezig om extensies te testen, te vervangen, enz.

[Lennie]

Bij Firefox kon je vroeger alleen addons maken die direct ingrepen in de browser. Firefox al ondersteunt sinds jaren minder ingrijpende addons zoals bij Chrome die niet afhankelijk zijn van de interne browser API.

Het zijn dus de oude die soms kapot gaan.

De handigste manier om bij een upgrade om te gaan met dat soort zaken is om de volgende addon te installeren:

https://addons.mozilla.or...ibility-reporter/?src=api

[Reactie gewijzigd door Lennie op 24 juli 2024 19:51]

[Verwijderd]

Het opgevoerde tempo zorgt ervoor dat nieuwe features sneller beschikbaar zijn, aldus de Mozilla-topman.

Afgezien van een enkele geek zit daar eingelijk niemand op te wachten.
Als er elke half jaar nieuwe features komen is dat snel genoeg.
Voor velen is zelfs dat nog te snel. Die hebben lievere een stabiel product waar langduring ondersteuning op wordt gegeven

[Reactie gewijzigd door Verwijderd op 24 juli 2024 19:51]

[Azzmodan]

Ja klopt niemand zit te wachten op een snellere browser die minder geheugen gebruikt en minder vastloopt؟