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.
| Version | Crashes per 100 active daily users |
|---|---|
| 3.6.20 | 1.8 |
| 4.0.1 | 1.6 |
| 5.0.1 | 1.4 |
| 6.0 | 1.6 |
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.
August 27th, 2011 at 6:14 pm
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.
September 6th, 2011 at 1:57 pm
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.