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 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.
Great, just what we need... more updates, downloads, and EULA changes.<p>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.<p>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..
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 ;)<p>anyways, I like having these aligned - one number less to keep track of
This seems like it might be some middle management trying to make a big 'impactful' change that won't really change anything...<p>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.
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).<p>Is there a way to make this permanent anyone is aware of?
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?<p>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?<p>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.
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.
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.