Chrome-webbläsaren skiljer sig från Chromium i sin användning av Googles logotyper
Google presenteras via ett blogginlägg, deras planer på att göra en förändring av releasecykelmodellen för din Chrome-webbläsare, för en kortare.
Google nämner att syftet med att göra förändringen är att för att minska tiden mellan att skapa en ny filial och börja betatestning, där betaversionen kommer att skapas två dagar efter att grenen skapats, istället för den nuvarande modellen som är 8 dagar.
Betan kommer att fortsätta att stabiliseras i 4 veckor. Således kommer förberedelsecykeln för en ny release att vara en vecka kortare.
Angående denna nya modell som planeras att tas i bruk i Chrome är det värt att nämna det är något liknande senaste cykel av uppdateringar som Canonical implementerade i Ubuntu (jag vet inte för närvarande om de var inspirerade eller togs som grund). Och det är han Canonicals 4/2-modell, strävar detta efter att kunna åtgärda korrigeringen av sårbarheter under en kortare period.
Eftersom som du nämnde så bygger Canonicals nya 4/2-modell på det faktum att två veckor efter starten av generationscykeln för nästa SRU (Stable Release Updates) kommer en separat SU-uppdatering att publiceras, som inkluderar korrigeringar endast för farliga sårbarheter och stora problem.
Till exempel, i fallet med den nya Chrome-modellen, med Chrome 119-grenen som ett exempel, nämns det att med den tidigare modellen skulle lanseringen av denna version förväntas den 3 oktober, men med den nya modellen kommer den att komma på 2 oktober, medan för releasen av betaversionen istället för att släppas den 11 oktober (föregående modell), skulle den släppas den 4 oktober (bara tre dagar efter releasen av den stabila versionen och när det gäller nästa stabila release som skulle vara Chrome 120 istället för att anlända den 7 november, den skulle lanseras den 31 oktober.
Vidare nämns också att nyligen har den interimistiska uppdateringsgenereringscykeln med sårbarheter förkortats, Med vilket det förväntas att förändringen kommer att gynnas vid testning av korrigeringar och upptäckande av fel. Även om det också nämns att en av de negativa punkterna med förändringen är att hackare kan dra fördel av synligheten för dessa korrigeringar och utveckla exploateringar att ansöka mot webbläsaranvändare som ännu inte har fått korrigeringen (detta utnyttjande av ett känt och korrigerat säkerhetsproblem är känt som en n-day exploit).
Chrome levererar en ny huvudversion var fjärde vecka. Mellan dessa stora utgåvor driver vi ut uppdateringar för att fixa säkerhetsbuggar och andra storslagna buggar. Vi schemalägger för närvarande en av dessa stabila kanaluppdateringar (eller "stabil uppdatering") mellan varje milstolpe. Från och med Chrome 116 kommer stabila uppdateringar att släppas varje vecka mellan milstolpar.
Och om tidigare, inom den fyra veckor långa cykeln för att skapa en ny huvudversion, korrigerande uppdateringar publicerades två veckor efter nästa version, med början med Chrome 4, började dessa uppdateringar bildas varje vecka i närvaro av sårbarheter . I fallet med att ta bort kritiska eller redan utnyttjade sårbarheter, som tidigare, kommer uppdateringen att släppas utanför schemat.
Det är värt att nämna att för de som är intresserade av att känna till Chrome-färdplanen kan du konsultera den från följande länk, För att kontrollera Chromiums releaseschema kan du läsa informationen i den här länken.
Som en personlig kommentar kan jag säga att att försöka ta itu med säkerhetsproblem och buggfixar på kortare tid är en extremt bra sak för användarna, men att ytterligare förkorta den stabila utgivningscykeln kan leda till någon typ av konflikt med användarna, utöver det faktum att de nya utgåvorna i de flesta fall bara kunde vara korrigeringar och vissa förbättringar och inte längre skulle presentera nya funktioner eller tillägg i funktionalitet som tidigare gjorts.
Slutligen om du är intresserad av att veta mer om detkan du kontrollera detaljerna i följande länk.