Google gaat Chrome vaker updaten
Google gaat Chrome vaker updaten. De zoekgigant wil de frequentie verdubbelen van eens in de 3 maanden naar elke 6 weken. Het bedrijf hoopt zo de gebruikerservaring, de interne planning en de werkdruk voor het personeel te verbeteren.
Volgens Google zou het verhogen van de updatefrequentie meerdere voordelen hebben. Zo krijgen gebruikers sneller nieuwe features te zien en hoeven zij niet meer lang te wachten op een update. De fabrikant stelt bovendien dat het updateschema voorspelbaarder wordt en dat daardoor de interne planning soepeler verloopt.
Tot slot wil Google de druk op zijn ontwikkelaars verlagen om de deadline van de aankomende update te halen. Als een ontwikkelaar van een feature de deadline dreigt te missen, moet het bedrijf naar eigen zeggen nu nog uit drie kwaden kiezen: óf de update verlaten, óf het personeel over laten werken óf de feature drie maanden later toevoegen. Door de hogere updatefrequentie is de impact van de laatste keuze aanzienlijk afgenomen omdat er dan weer snel een nieuwe update komt.
Reacties (66)
Allemaal leuk en aardig, maar komen er zo niet veel sneller vervelende bugs door de controles?
Worden die dan niet snel opgelost;)?
Misschien juist niet. Als je maar eens per drie maanden een release hebt en je feature is net op tijd af maar nog niet getest, dan gaat die mee. Wanneer je iedere zes weken een release hebt, stel je de feature misschien een release uit, zodat er goed getest kan worden.
Het is niet de release frequentie, maar het beleid dat invloed heeft op de hoeveelheid bugs die in een release blijven zitten. Een hogere release frequentie geeft je wel de mogelijkheid om een wat strakker beleid te hebben qua testen en dergelijke, omdat het minder erg wordt om iets een release uit te stellen.
Het is niet de release frequentie, maar het beleid dat invloed heeft op de hoeveelheid bugs die in een release blijven zitten. Een hogere release frequentie geeft je wel de mogelijkheid om een wat strakker beleid te hebben qua testen en dergelijke, omdat het minder erg wordt om iets een release uit te stellen.
Is af niet gewoon, af + getest?
Ligt eraan welke softwareboer je hebt. Bij Google, en dan vooral bij Chrome, hebben ze een zeer uitgebreide, grotendeels geautomatiseerde testprocedure. Elke feature die je toevoegt moet ook geleverd zijn met een test, en elke code die je toevoegt wordt gereviewed door een reviewer. Zie ook http://www.chromium.org/developers/contributing-code. Dit is dan voor de open source variant, maar dat is effectief hetzelfde product, en hetzelfde proces wordt erbij gebruikt.
Kan zelf zeggen dat dit een zeer effectieve methode is. Heb uit eigen software bugs gehaald die je anders pas tegenkwam als het al een tijdje draaide, en slechte gevolgen kan hebben (corrupte gegevens). Maar het is wel een kunst om uit te vinden wat te testen..
af is over het algemeen af + getest ja. het test gedeelte kan echter afgeraffeld worden en niet goed gebeuren.
(kijk naar de iphone 4)
(kijk naar de iphone 4)
Vaak zat ook af + geen tijd/geld om te testen.
Daarom hebben ze stable beta en dev releases 
Ik denk da ze wel slim genoeg zijn om te testen hoor. Niet getest is nog niet in deze update maar de volgende.
Daar gaat het nu net om. Dat ze makkelijker een feature naar de volgende updateperiode kunnen verschuiven omdat het nu toch maar 6 weken scheelt.
Lijkt me dat dit alleen maar de bug-ratio ten goede kan komen.
Daar gaat het nu net om. Dat ze makkelijker een feature naar de volgende updateperiode kunnen verschuiven omdat het nu toch maar 6 weken scheelt.
Lijkt me dat dit alleen maar de bug-ratio ten goede kan komen.
Waarom zou dat het geval zijn?
Google heeft gewoon een planning zo iets als Feature X is af binnen 3 maanden na de start van het project. Dus de volgende release gaan we hoe dan ook niet halen als er een vertraging is de release daarna ook niet maar we gaan niet van een vertraging uit.
Dus als over twee en een halve maand blijkt dat er toch vertragingen waren en het niet gaat lukken om het project op tijd af te hebben voor de aankomende release dan kun je dus kiezen om dan maar over te werken en als nog het werk op tijd af te krijgen (dat kan alleen als het haalbaar is om de vertraging goed te maken binnen de twee weken die je de tijd hebt... de andere optie dan maar de aankomende release overslaan is natuurlijk niet leuk maar soms de enige manier, als de feature echt heel erg belangrijk is en andere feature's niet tot hun recht zouden komen zonder deze feature dan kun je de release vertragen natuurlijk maar dat is echt de laatste optie.
Als je de releases korter op elkaar laat vallen dan zal het vertragen van een release minder voorkomen omdat het met kleinere intervallen steeds minder zin heeft om dat te doen. En dus zal dit minder voor gaan komen.
Voor de eindgebruiker is het grote voordeel dat we veel sneller nieuwe features zullen krijgen omdat als een feature bijvoorbeeld 2 weken duurt om te ontwikkelen en de ontwikkeling start 3 dagen voor een release dan hoeven we niet meer bijna 3 maanden te wachten maar nog maar ongeveer 5 weken voor het in een release verschijnt.
Voor de ontwikkelaars is het missen van een release een minder groot probleem de code blijft niet nog 3 maanden stil liggen maar maximaal 6 weken waardoor bijvoorbeeld voortborduren op een nieuwe feature makkelijker zal zijn omdat mensen de nieuwe feature veel sneller zullen kunnen gebruiken en zinnige feadback kunne geven op het idee om de feature uit te breiden etc.
Ik zie totaal geen reden waarom een kortere release cycle zou leiden tot meer bugs.
Google heeft gewoon een planning zo iets als Feature X is af binnen 3 maanden na de start van het project. Dus de volgende release gaan we hoe dan ook niet halen als er een vertraging is de release daarna ook niet maar we gaan niet van een vertraging uit.
Dus als over twee en een halve maand blijkt dat er toch vertragingen waren en het niet gaat lukken om het project op tijd af te hebben voor de aankomende release dan kun je dus kiezen om dan maar over te werken en als nog het werk op tijd af te krijgen (dat kan alleen als het haalbaar is om de vertraging goed te maken binnen de twee weken die je de tijd hebt... de andere optie dan maar de aankomende release overslaan is natuurlijk niet leuk maar soms de enige manier, als de feature echt heel erg belangrijk is en andere feature's niet tot hun recht zouden komen zonder deze feature dan kun je de release vertragen natuurlijk maar dat is echt de laatste optie.
Als je de releases korter op elkaar laat vallen dan zal het vertragen van een release minder voorkomen omdat het met kleinere intervallen steeds minder zin heeft om dat te doen. En dus zal dit minder voor gaan komen.
Voor de eindgebruiker is het grote voordeel dat we veel sneller nieuwe features zullen krijgen omdat als een feature bijvoorbeeld 2 weken duurt om te ontwikkelen en de ontwikkeling start 3 dagen voor een release dan hoeven we niet meer bijna 3 maanden te wachten maar nog maar ongeveer 5 weken voor het in een release verschijnt.
Voor de ontwikkelaars is het missen van een release een minder groot probleem de code blijft niet nog 3 maanden stil liggen maar maximaal 6 weken waardoor bijvoorbeeld voortborduren op een nieuwe feature makkelijker zal zijn omdat mensen de nieuwe feature veel sneller zullen kunnen gebruiken en zinnige feadback kunne geven op het idee om de feature uit te breiden etc.
Ik zie totaal geen reden waarom een kortere release cycle zou leiden tot meer bugs.
Snellere updates, voordelen volgens het artikel zijn:
- niet langer wachten op updates
- nieuwe features zijn er sneller.
Lol, dat lijkt me pretty pretty obvious nee?
- niet langer wachten op updates
- nieuwe features zijn er sneller.
Lol, dat lijkt me pretty pretty obvious nee?
Nieuwe features sneller hoeft niet per se obvious te zijn.
Developers hebben nog steeds tijd nodig om het te ontwikkelen.
Developers hebben nog steeds tijd nodig om het te ontwikkelen.
Klopt, maar als feature X 5 maanden na de laatste release af en getest is, zou hij in de oude situate nog 7 weken mogen wachten. Nu nog maar een week tot de volgende release.
Een beetje flauw van mij, maar hoeveel nieuwe features heb je nodig in een browser? Dat kreng moet kunnen uploaden, downloaden en browsen. Dan heb ik de hoognodige features wel genoemd. Maar het is wel een aardige dienst van ze.
Beetje flauw van mij, maar waarom zou je überhaupt naar een andere browser overstappen als je functionele eisen zo beperkt zijn? Dan kun je bij wijze van spreken ook nog toe met een browser uit 1995.
ik denk dat dit goed zal zijn voor dit product want als er een bug gevonden is of er nieuwe content is duurde het altijd eeuwen vooraleer er een update is.
Zo veel verschil zal het niet maken.
Als een bug niet in de eerste 3 tot 4 weken na een release ontdekt wordt zal het niet opgelost raken tegen de volgende release. Twee weken voor fix en testen is weinig. Bijgevolg zal de fix een release overslaan en pas na 8 weken uitkomen.
Hoewel er dus meer releases zijn, zal het lijken alsof het langer duurt (2 releases ipv 1) alvorens een probleem opgelost wordt.
De realiteit is dus dat niets sneller opgelost gaat worden, maar dat het de schijn zal hebben om trager te gaan wat ook niet waar is.
Als een bug niet in de eerste 3 tot 4 weken na een release ontdekt wordt zal het niet opgelost raken tegen de volgende release. Twee weken voor fix en testen is weinig. Bijgevolg zal de fix een release overslaan en pas na 8 weken uitkomen.
Hoewel er dus meer releases zijn, zal het lijken alsof het langer duurt (2 releases ipv 1) alvorens een probleem opgelost wordt.
De realiteit is dus dat niets sneller opgelost gaat worden, maar dat het de schijn zal hebben om trager te gaan wat ook niet waar is.
En in het huidig systeem van nu zou die dus sowieso 8 weken later uitkomen.
Dan hoop ik toch dat ze wat aan hun versienummering doen, Chrome is nu 2 jaar uit en ze zijn al aan versie 6 bezig
5.0.375.99 beta 
6.0.472.0 Dev
6.0.476.0 Trunk 
1.0.0.1 Legacy 
6.0.649.6 Super?
Nou als het de zesde versie is is nummer 6 niet zo raar toch?
Jawel. Ze racen door de versie nummers heen om maar zo snel mogelijk bij IE 8 en Opera10 te komen.
Wat voor nut hebben ze daar nou bij? Google adverteert helemaal nergens met de versienummers.
Omdat het nu ook geen nut heeft omdat ze een lage versie nummer hebben. 'Simpele' gebruikers denken heel plat dat Internet explorer 8 wel eens beter kan zijn dan Chrome 6.
Zulke simplisten gaan niet op zoek naar een alternatieve browser.
Ik hoop dat er niet al te veel van zijn, want zelfs mijn vader snapt dat een versienummer voor één product geld en dat Firefox 3.6 dan beter zou moeten zijn als 3.5.
(niet dat de regel dat een zelfde product met een hoger versienummer altijd beter zou moeten zijn, de meeste software bedrijven hebben wel eens een wat mindere versie er tussen zitten )
Over 'simpele' mensen gesproken, deze beschouwen veel updates overigens als een nadeel omdat het in de weg van je normale werk zit.
Ik hoop dat er niet al te veel van zijn, want zelfs mijn vader snapt dat een versienummer voor één product geld en dat Firefox 3.6 dan beter zou moeten zijn als 3.5.
(niet dat de regel dat een zelfde product met een hoger versienummer altijd beter zou moeten zijn, de meeste software bedrijven hebben wel eens een wat mindere versie er tussen zitten
)Over 'simpele' mensen gesproken, deze beschouwen veel updates overigens als een nadeel omdat het in de weg van je normale werk zit.
[Reactie gewijzigd door Xthemes.us op vrijdag 23 juli 2010 21:32]
Was het maar waar dat alleen simplisten (leuk woord trouwens) zo denken. Menig manager denkt aan het versienummer heel wat af te kunnen lezen. Zo veel zelfs dat het mogelijk / nuttig lijkt om beleid te formuleren puur en alleen gebasseerd op versienummers. Zoals: "Versie 1.0 mag je hier niet installeren, eerst wachten tot de bugs er uit zijn"
Tja maar dat is wel een duidelijke release policy. Veel bedrijven die het zo doen.
regel is over het algemeen dat de 1.0 versie te vroeg is om in een live omgeving te draaien en minimaal een Servicepack 1 moet bevatten mocht het rijp zijn voor uitrol.
Dat beleid is dus zeker wel nuttig, geen beleid is slechter. Je moet minimaal iets formuleren en als je het overlaat aan menig IT' er dan worden zelfs Beta versies niet geschuwd.
regel is over het algemeen dat de 1.0 versie te vroeg is om in een live omgeving te draaien en minimaal een Servicepack 1 moet bevatten mocht het rijp zijn voor uitrol.
Dat beleid is dus zeker wel nuttig, geen beleid is slechter. Je moet minimaal iets formuleren en als je het overlaat aan menig IT' er dan worden zelfs Beta versies niet geschuwd.
meestal is versie 1.0 juist de stabiele versie ... na jaren van 0.x versies ....
dat was toch ook zo met firefox...
dat was toch ook zo met firefox...
Ja en IE is al sinds augustus 1995 bezig met hun browser en zijn bij nummero 8 
(bijna 9)
(bijna 9)Ja dat is marketing denk ik. Ze willen het 'eerlijk' doen en dus niet ineens van versie 4.x naar 6 gaan (ahem Netscape), maar als Internet Explorer zometeen bij versie 9 is dan wil Chrome daar natuurlijk ook zitten.Chrome is nu 2 jaar uit en ze zijn al aan versie 6 bezig
Verder heb je natuurlijk busladingen met zich blind starende marketing types die onzin uitkramen als: "We installeren nooit versie 1" of "We installeren nooit x.0 versies". Alsof een hoger versienummer een garantie is voor een stabiel systeem?
Als je de kwaliteit van software wilt beoordelen dan zul je of zelf uitgebreid moeten testen, of je zult kennis moeten nemen van de bevindingen van anderen die dat gedaan hebben. Versienummers zeggen helemaal niks!
Ik ken de achtergrond niet, maar stel dat Netscape de 5e versie gewoon zelf heel slecht vond dat ze die maar niet hebben uitgebracht. Versienummers worden bepaald door wat je er aan verbouwt, het is niet zomaar een nummertje.... Ze willen het 'eerlijk' doen en dus niet ineens van versie 4.x naar 6 gaan (ahem Netscape)...
De ontwikkelingen gaan sowieso heel erg snel. De features die nu in Dev Channel naar boven komen zijn heel erg fijn.
http://googlechromereleases.blogspot.com/ heeft iedere paar dagen een nieuwe update. Ik gebruik de Dev Channel zelf voor thuisgebruik, en vind de snelle updates een goede toevoeging.
Dus, de retail versie van Chrome gaat dit nu ook vaker krijgen, ik kan dit alleen maar toejuichen!
http://googlechromereleases.blogspot.com/ heeft iedere paar dagen een nieuwe update. Ik gebruik de Dev Channel zelf voor thuisgebruik, en vind de snelle updates een goede toevoeging.
Dus, de retail versie van Chrome gaat dit nu ook vaker krijgen, ik kan dit alleen maar toejuichen!
"Old school's not cool! Google Chrome hasn't been updated for a while because it hasn't crashed or been restarted."
"Update now?"
"Update now?"
Vind de updates anders behoorlijk snel gaan met de daily builds die ik hier gebruikt
Maar mooi dat op deze manier de "normaale" gebruikers de nieuwe features ook sneller binnenkrijgen
Maar mooi dat op deze manier de "normaale" gebruikers de nieuwe features ook sneller binnenkrijgen
Zolang de browser geen OS-native feel heeft blijf ik bij Safari
Op Windows 7 voelt die redelijk native
Grootste gebruikersgroep, meeste aandacht?
Daarnaast heeft microsoft een veel minder streng beleid m.b.t. UI guidelines en hebben hun eigen programma's (met name office) hier meestal lak aan. Waardoor je helemaal geen eenduidige interface gewend bent.
Een browser is sowieso vaak het programma dat het meest afwijkt van een normaal programma omdat het gaat om de content die word weergegeven en die zijn eigen functionaliteit verzorgt. Sterker nog, het verstoppen van zo'n menubalk die nooit wordt gebruikt wordt alleen maar toegejuicht door de gebruikers en overgenomen door de andere browsers.
* Xthemes.us zou overigens een Qt als aanvulling op de GTK versie voor Linux wel op prijs stellen, lelijke vierkante menu's en instellingen schermen
Zou waarschijnlijk ook vrij makkelijk zijn(?) door te spieken hoe dingen worden gedaan met Qt's eigen webkit versie.
[edit]
Het grote voordeel van Chrome is natuurlijk ook dat het zich niet native gedraagd, het hoopt de dingen op een betere manier te doen.
Het grootste verschil zal dan nog in het proces per tab verhaal zitten waar aan gewerkt word om dit ook in Safari te krijgen dacht ik. (beide zijn webkit, en squirrelfish/v8 zijn beide erg snel met javascript dus daar zit weinig verschil)
Daarnaast heeft microsoft een veel minder streng beleid m.b.t. UI guidelines en hebben hun eigen programma's (met name office) hier meestal lak aan. Waardoor je helemaal geen eenduidige interface gewend bent.
Een browser is sowieso vaak het programma dat het meest afwijkt van een normaal programma omdat het gaat om de content die word weergegeven en die zijn eigen functionaliteit verzorgt. Sterker nog, het verstoppen van zo'n menubalk die nooit wordt gebruikt wordt alleen maar toegejuicht door de gebruikers en overgenomen door de andere browsers.
* Xthemes.us zou overigens een Qt als aanvulling op de GTK versie voor Linux wel op prijs stellen, lelijke vierkante menu's en instellingen schermen
Zou waarschijnlijk ook vrij makkelijk zijn(?) door te spieken hoe dingen worden gedaan met Qt's eigen webkit versie.
[edit]
Het grote voordeel van Chrome is natuurlijk ook dat het zich niet native gedraagd, het hoopt de dingen op een betere manier te doen.
Het grootste verschil zal dan nog in het proces per tab verhaal zitten waar aan gewerkt word om dit ook in Safari te krijgen dacht ik. (beide zijn webkit, en squirrelfish/v8 zijn beide erg snel met javascript dus daar zit weinig verschil)
[Reactie gewijzigd door Xthemes.us op vrijdag 23 juli 2010 21:45]
En hoe zou het internet zijn als letterlijk elke Windows user dat ook zou denken?
*posted from Chrome*
*posted from Chrome*
Misschien heeft Safari een OS native feel *op de Mac*. Ik heb de Windows versie een tijd gebruikt en die voelt dus alles behalve OS native aan!
Volgens mij kan dit niet anders dan goed nieuws zijn! Sneller updates is sneller bugfixes !
"Het bedrijf hoopt zo de gebruikerservaring, de interne planning en de werkdruk voor het personeel verbeteren."
Bovendien zit hier ook wat in !
!"Het bedrijf hoopt zo de gebruikerservaring, de interne planning en de werkdruk voor het personeel verbeteren."
Bovendien zit hier ook wat in
!
"verbetering in de werkdruk", daar zullen de werknemers echt op gewacht hebben, sinds wanneer is dit een gewenste marketingsslogan ?
Voor google zijn de werknemers net zo belangerijk als de gebruikers.
Natuurlijk heeft de gemiddelde huisvrouw in Nederland niks aan deze reden. Maar als je in de achterhoofd hebt dat Google op dit moment de beste werkgever is in de ICT, dan zul je het wel begrijpen denk ik
Natuurlijk heeft de gemiddelde huisvrouw in Nederland niks aan deze reden. Maar als je in de achterhoofd hebt dat Google op dit moment de beste werkgever is in de ICT, dan zul je het wel begrijpen denk ik
Waar lees jij dat dat een marketingsslogan is?
Het geeft aan dat hun developers belangrijk zijn voor hun, dat geeft het bedrijf een positief imago, dus moet het wel marketing zijn.
Inderdaad, als je een groot bedrijf bent dan zijn dat soort dingen wel wat je imago meer kan schaden dan wanneer je een klein bedrijfje bent. Je imago als groot bedrijf is belangrijker. Dus dan is het ook qua marketing handig. Stel dat alle devvers (lijkt wel of er dewers staat maargoed) weg zouden lopen omdat de werkdruk te hoog is, dan ligt ook het werk stil. Niet goed voor de imago = niet goed voor de omzet.
[Reactie gewijzigd door Grrmbl op zaterdag 24 juli 2010 13:09]
Verlichting van de werkdruk levert bijna automatisch hogere kwaliteit op. Een developer kan dan nog even wat extra tijd besteden aan het echt netjes afmaken en testen van de feature. Developer happy, product beter 
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
