Hacker News Reader

Comment by AshleysBrain | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com