We’re doing something quite new things with updates as part of the FF3.5 release. Something that, as far as I know, has never been done before in Mozilla, and which is really really cool.
- On the day of the Firefox 3.5 release, existing Firefox3.0 users will be able to upgrade to FF3.5 simply by doing “Help->CheckForUpdate”.
- The release of FF3.5 starts a 6month End-of-Life period for FF3.0.x. For those 6 months, we’ll have major update offers available all the time to those FF3.0.x users.
Sounds boring, and kinda simple. To understand just how massive this improvement is, we need to compare this with what happened for FF3.0 and FF2.
| 2.0.0.x | 3.0.x | 3.5.x | |
| Days between release and initial MU offer: | 248 | 65 | 0 |
| Percentage of EOL period that MU was available: | 0% | 21% | 100% |
This means people should be able to migrate from FF3.0->FF3.5 faster then we have historically seen people migrate from FF1.5->FF2.0 or FF2.0->FF3.0. How how much faster will people migrate? We don’t know yet, we’ve never done this before.
Obviously, we need to make a product that is compelling and which people *want* to migrate to. But at least now, with these infrastructure changes in place, any user who wants to upgrade will always be able to!
Let us know what you think over the coming months.
For the curious, here’s details on how we did it:
1) Background data on previous dates
Firefox1.5 -> Firefox2:
=======================
24Oct2006: FF2.0.0.0 released, start of FF1.5 End-of-Life.
30May2007: end of FF1.5 End-Of-Life.
In those 219 days, users were never able to major update. Our first major update available for FF1.5 users was 29June2007, a month *after* the formal End-Of-Life.
Or, put another way: Major update were available 0% of the End-of-Life
period.
Firefox2.0 -> Firefox3.0:
=========================
17Jun2008: FF3.0.0 released, start of FF2 End-Of-Life.
17Dec2008: end of FF2 End-Of-Life.
In 183 days, users could only major update 39 out of 183 days. None of those 39 days were during the initial peak of public attention around release day.
Major update were available 21% of the End-of-Life period.
Firefox3.0 -> Firefox3.5:
=========================
30Jun2009: FF3.5.0 released, start of FF3.0 End-Of-Life.
31Dec2009: (approx) end of FF3.0 End-Of-Life.
In those 184 days, we expect major update to always be available, including during initial public attention around release day.
Major updates should be available 100% of the End-of-Life period.
2) WebDev made a small, but important, change to the update infrastructure. This change means that manual CheckForUpdates major update can now be throttled differently to “background-idle” major update.
This means we can issue, and re-issue, major updates as often as we like to users who manually CheckForUpdates… without having to worry that we are annoying “background-idle” users by re-prompting them again and again with a major update dialog box each time.
Users who passively wait for major updates will now only be shown a major update dialog box when Beltzner/Sam ask for the “background-idle” major update to be unthrottled. They can make that decision based on what they think is best for the product, the user experience, and their user-update-fatigue discussions.
Furthermore, as most of the RelEng and QA work was already done earlier, as part of the CheckForUpdates work, this means that Beltzner/Sam can make those “background-idle” decisions without worrying about causing much extra work for RelEng or QA.
(For details on race conditions where people dont see the major update dialog box and on the “update fatigue” debate, see: here, here, here, here, and finally here.)
3) Nick Thomas led a bunch of significant cleanup in RelEng infrastructure, so we can now create major updates quite easily and reliably.
We used this improved infrastructure to create the FF2.0.x-> FF3.0.x major update offers.
We also used this to create “fake” FF3.0.x -> FF3.5beta/rc major update offers several times over the last 6 months in advance of the FF3.5 release. QA were able to test each of these, and file blockers in FF3.5 as needed. By the time it comes to release day, QA have already tested major update several times, including on the latest FF3.5rc3.
We will also be using this to create a new major update offer from FF3.0.x -> FF3.5.x., every time as we ship a new FF3.0.x security release.
There are a few different scenarios we had to handle for that (see the photo of whiteboard before we moved office, for red lines in scenarios A, B, C, D!) but they’re all covered.
This change is important because it fixes a problem described here where users could see a major update offer only until we shipped the next security release. The new security release blocked access to the pre-existing major update. Now, by re-issuing a new major update at the same time as the new security release, users will *always* be able to see a major update offer.
Thats it.
Hopefully all that made sense. I know its a obscure corner in the infrastructure, but I hope this post explains why all this is strategically important to Mozilla and to Firefox.
While I dont normally like respins, in this one case, I was happy for the FF3.5beta99 respin, as it suddenly gave us ~3 hours before we would need the signing machine again. So, Aki, John Ford and myself quickly moved the mobile devices from Aki’s desk, and the signing machine keymaster out of the server room, into two cars, and drove over in careful slow convoy to the new building. Thankfully Aki thought to put all the mobile devices into a portable guitar base pedal case, which made it “easy” to carry.
…although keymaster looked too unsecured in the back seat like that, so Aki sat in the back, and physically held it for the drive.
You must be logged in to post a comment.