Rapid releases and crashes

In the months before Firefox's first rapid release, one concern echoed throughout engineering: crashes.

We had always relied on long stabilization periods to get crash rates down. Firefox 4 would be our last high-stability release. We hoped improvements on other aspects of quality would outweigh the decreased stability.

But then something surprising happened. We released Firefox 5, and Firefox didn’t get crashier.

VersionCrashes per 100 active daily users

KaiRo’s explanation parallels what I’ve seen helping with MemShrink:

  • The channel cascade gives each release 12 weeks of pure stabilization.
  • The channel audiences help by comparing alphas to alphas.
  • The short cycles enable backouts and reduce the desire to land half-baked features.

“Rapid release” doesn't mean building Firefox the way we always have, x times faster. It’s a new process that fits together in beautiful yet fragile ways.

2 Responses to “Rapid releases and crashes”

  1. Robert Kaiser Says:

    Be careful with those crash rate numbers. They are so shaky and add up so many different things, including how spread malware is and things like that, you can’t use them for a comparison usefully the way you are trying here. What you are showing here for someone who is monitoring crashes daily is 1) that using those rates publicly is dangerous and 2) all those releases are roughly equally stable. Oh, and that having fewer Windows users on a version (5.0.1) makes it look slightly better.

  2. Scott Kinney Says:

    My experiences to date with 6.0.1 and 6.0.2 are that it crashes multiple times per day. I admit a sample of one may not carry much weight, but the frequency of crashes since updating with the ‘stability release’ is frustrating and annoying and the lack of attention is infuriating as well.