Well, if by "fiasco" we mean "a random person wrote some random observations about his computer and chrome on some random website" then, probably they don't really need to follow up on it...
Loren Brichter is a long-time Mac developer and hardly a "random person"; and his claims were based on anecdata from multiple machines and Twitter reports. Pareidolia is certainly a reasonable null-hypothesis (similar to 99% of computing rain-dances, like repeated defragmentation, or "closing" iOS apps). But assuming the problem isn't completely coincidental or imagined, it would still be good to get to the bottom of it, whether the root problem is Apple's or Google's.
Release cadence and performance issues are orthogonal.
Frequent releases just mean you get updates as they become available. That doesn't mean they can't take on longer-term issues that need several release cycles to complete.
Chrome project has a pretty robust system of continuous benchmarking where regressions are automatically detected and filed as bugs, and the causing CLs are automatically found by bisection. For example, a recent regression:
so Chrome 94 will be released on 09/21 and Firefox 94 on 10/05 .. what a coincidence, seems like 'my version number is bigger then yours' is still a thing in 2021 ;)
anyways, I like having these aligned - one number less to keep track of
Maybe we'll see versioning ala Ubuntu in the future, "Firefox 21.03.04" for todays release. Append more digits if you start doing more than one per day.
I wish the evergreen browsers would ease back on the pace of releases. Most sites and apps can’t use bleeding edge features in production anyway for a variety of reasons. One of those reasons is low quality of implementation, for example if a feature is supported in theory but the rendering looks awful in one or more major browsers when it’s used in practice. Another is inconsistent implementation across browsers that need to be supported. Both of these areas have suffered noticeably in the modern era of rolling updates and the dubious concept of “living standards”. With the increasing significance of the web as an application platform and not just a medium for content delivery, developers need stability and clear specifications or the quality and longevity of their own products will inevitably suffer.
But developers need to support the browsers their audience choose to use, and as sad as it is, Firefox simply doesn’t have the market share today that it once did. Even if my amazing new web app runs perfectly in Firefox ESR, that isn’t going to help me if Chrome pushes out an update that breaks something for half my users.
I always thought that for a project this size, a 6 week release cycle was already super aggressive. We came from pretty much annual releases back in the IE days, so it made a huge difference to go to rapid releases. Does trimming another 2 weeks off really make a big difference to how quickly features arrive? I feel kind of sceptical that it's a meaningful difference. I would also guess a risk is that with less time on the pre-stable channels for testing, there might actually be more bugs and issues as a result. I'd be interested to hear the arguments in favour, which the blog post doesn't seem to go in to any real detail about.
I believe it's a mistake to assume that this change is solely to deliver features to users faster. There are all kinds of other things in Chrome other than end-user features.
One important thing would be security updates.
Chrome also has mechanisms that feed back into core Google businesses, so this also might improve Google's ability to iterate on those faster, gather feedback and make business decisions faster, etc.
Personally I want to avoid Google's "core business" as much as possible, so if that's a major reason for this change then it's even more motivation to stay off of Chrome.
(This is all speculation, since Google doesn't really have any credibility to me anymore, so I won't believe any official reasons they have for doing this.)
> I would also guess a risk is that with less time on the pre-stable channels for testing, there might actually be more bugs and issues as a result
Is it also possible that a shorter window would allow less number of features being in flux in each release? Perhaps that actually leads to easier bug triaging, etc.
On the other side, if you release the software more often, there is an higher probability for a bug to end up in the hands of the users instead of being found internally.
Given that most people won't ever report a bug, do like firefox and give to willing people a nightly/developer/preview edition and to regular people something released less often.
IMHO, this isn’t a compelling argument. For a large application like a browser, even releasing every few weeks, surely there will not be two or ten changes since the last release but probably hundreds. If a bug makes it into a new release and none of the developers sees the report and immediately realises where it probably came from, won’t they look for a more systematic method to identify when it started happening than manually examining every change since the last release?
The latency is higher than that, but just hidden by pipelining. It seems that this should reduce latency from commit to prod by 3 weeks (from about 13w to 10w).
In a sprint cycle, you really need to consider timing of both one and two sprints if you want to try to maintain stable sprints. If a bug comes in just after the start of a sprint, it may be until the end of the next sprint that it ships.
In this case, 2 weeks cuts a month off your "2orst" case delivery timeframe.
I know someone has to justify employing those people, but honestly, where is the browser that just works by default for the 99.9% of simple use cases and isn't a resource hog?
We don't need a separate sandboxed OS eating 4GB of RAM just to display 5KB of text (and 2MB of javascript). Maybe focus on that, if any Googlers are reading.
Because other browsers keep adding features, and then web sites start using those features. Any browser that stops adding features eventually finds itself unable to display certain sites, and loses users to browsers that can display those sites.
Which is to say (channeling Zawinski's Law), any browser that fails to add features will eventually be replaced by a browser that does.
Google's strategical view is to make web browser as capable as the native apps on mobile (mostly to counterbalance the iOS native apps' walled garden). It's called Project Fugu.
I don't expect them to stop shipping any time soon.
(Meanwhile Firefox's agenda is to push web forward but keep the balance; and Apple's agenda is to keep browser fast with minimal bloat, and lately privacy as an anti-Google selling point; and evolve the browser in other aspects just to not become the next IE and avoid lawsuits for blocking other rendering engines on iOS).
Thank you, but this is not necessary. If you ever asked for feedback (but you haven't) and based your actions on it (which you won't), you would make the release cycle much slower, you would inform the user about the upgrade, you would tell them which options are going to disappear and what will be broken, and you would give them the option to at least delay the upgrade. You also would ask their permission to run the Software Reporter tool, and it wouldn't report its findings to you.
But you don’t understand google engineers know best, they know what’s good for you my sweet summer child, you’re just a toddler who needs to be cradled and kept from ever being able to make decisions.
Just because the release cycle is faster, doesn't mean that features spend less time in alpha/beta channels. Evergreen browsers release features behind flags, and those features can sit sometimes for years before they're turned on by default in the public release channel.
Great, just what we need... more updates, downloads, and EULA changes.
I am tired of updating everything, and it often leads to rushed/less performant software because - hey we'll fix it soon anyway as long as we meet the deadline right? Or, even worse, like Microsoft openly using customers as beta testers.
Also, anyone notice these days how we used to be excited about buying or getting an "upgrade" and now we get pestered about "updates"... interesting semantic difference..
Maybe it's just me but I can't remember the last time I had to think about a chrome update/download/EULA change. Personally I think that's great, they aren't things I want to spend my time on so if they're automated than all the better imo.
Google wants to own the entire web just like Microsoft did when they shipped IE6, but somehow the people who were mad when Microsoft did it actually love that Google is doing it.
Even if they managed to make releasing easier for themselves and can keep the pure release overhead the same this can impact development. These shorter release cycles can make it harder to make larger changes and can add overhead for breaking and coordinating changes across releases.
Are there any upcoming versions where they plan to do something in particular? Like force manifest v3 perhaps? This sounds like a move to make some transition happen sooner.
52 comments
[ 1.7 ms ] story [ 101 ms ] threadI've always wondered what the slowdown with having chrome or not was and this could explain it.
Just now noticed the bug-tracker thread: https://bugs.chromium.org/p/chromium/issues/detail?id=115840...
Frequent releases just mean you get updates as they become available. That doesn't mean they can't take on longer-term issues that need several release cycles to complete.
https://bugs.chromium.org/p/chromium/issues/detail?id=117656...
What, in your expert opinion, is missing from this regime?
anyways, I like having these aligned - one number less to keep track of
One important thing would be security updates.
Chrome also has mechanisms that feed back into core Google businesses, so this also might improve Google's ability to iterate on those faster, gather feedback and make business decisions faster, etc.
Personally I want to avoid Google's "core business" as much as possible, so if that's a major reason for this change then it's even more motivation to stay off of Chrome.
(This is all speculation, since Google doesn't really have any credibility to me anymore, so I won't believe any official reasons they have for doing this.)
Is it also possible that a shorter window would allow less number of features being in flux in each release? Perhaps that actually leads to easier bug triaging, etc.
Disclaimer: Work at Google, but not on Chrome.
If you release two changes at once and a bug appears, you look at those two changes.
If you release ten changes at once and a bug appears, you have ten things to look into.
In either case, you do a bugfix release, but finding the source of the bug is much easier if you do smaller releases.
In this case, 2 weeks cuts a month off your "2orst" case delivery timeframe.
I know someone has to justify employing those people, but honestly, where is the browser that just works by default for the 99.9% of simple use cases and isn't a resource hog?
We don't need a separate sandboxed OS eating 4GB of RAM just to display 5KB of text (and 2MB of javascript). Maybe focus on that, if any Googlers are reading.
Because other browsers keep adding features, and then web sites start using those features. Any browser that stops adding features eventually finds itself unable to display certain sites, and loses users to browsers that can display those sites.
Which is to say (channeling Zawinski's Law), any browser that fails to add features will eventually be replaced by a browser that does.
I don't expect them to stop shipping any time soon.
(Meanwhile Firefox's agenda is to push web forward but keep the balance; and Apple's agenda is to keep browser fast with minimal bloat, and lately privacy as an anti-Google selling point; and evolve the browser in other aspects just to not become the next IE and avoid lawsuits for blocking other rendering engines on iOS).
Up to you to choose your preferred one.
I am tired of updating everything, and it often leads to rushed/less performant software because - hey we'll fix it soon anyway as long as we meet the deadline right? Or, even worse, like Microsoft openly using customers as beta testers.
Also, anyone notice these days how we used to be excited about buying or getting an "upgrade" and now we get pestered about "updates"... interesting semantic difference..
I don't restart that often and I almost constantly have the nagging "update" button in chrome.
Changing from a 6 week release cycle to a 4+8 week release cycle seems to be exactly that - in reality, nothing will really change.
Is there a way to make this permanent anyone is aware of?