Speeding up Chrome's release cycle | Hacker News Reader

Speeding up Chrome's release cycle

blog.chromium.org

77 pointstwapi51 comments

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.)

If your goal is faster security updates you need bugfix releases, not faster major releases.

> 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.

Disclaimer: Work at Google, but not on Chrome.

Why not just do bugfix releases? Much less risk...

That's not the issue.

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.

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 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.

I mean, Firefox ESR works pretty well.

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.

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.

Just because they don't make it explicit doesn't mean its not changing. I could be wrong though.

Do you restart your computer often?

I don't restart that often and I almost constantly have the nagging "update" button in chrome.

I think means a restart of chrome is necessary, not a restart of the whole machine.

Yea, I understand. I personally never restart Chrome, unless I'm doing a full computer restart.

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.

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

I don't know that I'm ready for these to be in triple digits.

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.

And... Fail when you reach 256 releases per day, or the year 2256.

I rather them to slow down and address the performance issues.

Have they given any follow-up to the https://chromeisbad.com fiasco?

Has there ever been a deeper investigation into this that goes beyond "I did a thing on my computer and something changed somehow"?

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...

I think it's important and may explain a lot. The fact that they started looking into this is a good sign.

I've always wondered what the slowdown with having chrome or not was and this could explain 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.

Just now noticed the bug-tracker thread: https://bugs.chromium.org/p/chromium/issues/detail?id=115840...

Looks like a MacOS issue to me. I used Chrome for years on my x201 with i3, it idled only a few degrees above room temp with Chrome open.

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:

https://bugs.chromium.org/p/chromium/issues/detail?id=117656...

What, in your expert opinion, is missing from this regime?

This seems like it might be some middle management trying to make a big 'impactful' change that won't really change anything...

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.

Google: Making it even less likely there's anything other than Blink that implements the most recent HTML* spec since 2013.

Every time that Chrome updates I have to give it macOS permission to access my location (if I want my location available to any web page at least).

Is there a way to make this permanent anyone is aware of?

This is an arms race to keep control of their browser market share.

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.

Why aren't browsers feature-complete?

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.

> Why aren't browsers feature-complete?

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).

Up to you to choose your preferred one.

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.

Extended support release = 8 weeks? lol

Now if Safari would only do the same...

For me, Safari is much better with resources and generally faster. If longer release cycles is what maintains that I’m fine with it.

Performance has gotten really bad recently, I don't know if it is GPU drivers or Chrome's fault, but it has gotten very stuttery.

It might be fault of websites too, they are constantly adding new features and "improving UX".

    * {
       filter: none !important;
       transition: none !important;
    }

newest css reset addition

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.

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.

Reply on news.ycombinator.com