After the last few blog posts [1], [2], [3] explaining details of some gotchas, here are a few mechanical ideas which might help. I’m not sure which, if any, make sense to try, but wanted to point out some new options we have available to us now after infrastructure improvements over the last year, and would love to hear what people thought.

1) Make major update available on the day of a release but only visible to users on latest dot release who do manual “check for updates”.

To take a concrete example, this would mean on the day of the FF3.5 release, that any user on the latest FF3.0.x release would be able to “check for updates” and immediately major update to FF3.5. Explicitly only users who were on the latest FF3.0.x and who actively “check for updates” would get this offer. Any users who are on older FF3.0 releases who do “check for update” would be updated to the latest FF3.0.x release.

This new option is only possible because of pre-release work done by both RelEng and QA, to verify that major update from FF3.0.n->FF3.5rc goes smoothly before the FF3.5 release, and an enhancement to AUS by
morgamic. We first practiced this in the lead up to the FF2->FF3.0 release, and were able to do major update much faster and smoother as a result, but the FF3.5 release will be first time we do this live on release day. Why is doing this on release day so important?

• Better mindshare: Mozilla typically gets more attention/blogs/press coverage on major release days. Making the most of this momentum in user mindshare by having major updates available and waiting for users who want them seems useful.
• Better experience for existing users: During the FF3.0 release, we saw an abnormally high spike in number of people doing manual “check for updates” on release day. We also saw a drop in FF2 users and an increase in FF3 users long before we released our first FF2->FF3 major update. One theory was that FF2 users saw press coverage about the new FF3.0 release, did “check for updates”, saw “no update available” so then manually downloaded FF3 and do a pave-over install. We can make the upgrade experience for our existing users better by letting any existing user who does “check for updates” get the major update, instead of having to manually download + pave-over manual install.
• Safer: A user on older FF2 who did check for updates would first get the update to FF2.0.0.20, and if they do “check for updates” again, would get the FF3.0 update. What we’d like to avoid is having users on old FF2.x doing paveover installs of FF3.0, and potentially discovering unknown migration bugs that we have not tested for. Having users follow a tested migration path seems safer.
• This would *not* do major update offers to idle users, only to users who explicitly take manual steps seeking out new release. This addresses worries about a) too much load on mirrors on release day and b) users upgrading to something that has some critical bug we don’t know about yet.

2) Every time we do a dot-release on new release line, make a new major update offer available to the older release line.

This approach basically views each major update offer as a new “security release” for the EOL’d older product line. For example, if we did this today, it would mean that whenever we release a new FF3.0.7, we would also release a new FF2.0.0.20->FF3.0.7 major update offer… and later when we release a new FF3.0.8, we also release a new FF2.0.0.20->FF3.0.8 major update offer.

• this would mean that users on the older FF2.0 release will be prompted to major update as often as users on FF3.0.x are prompted for new security releases. If there are concerns about update fatigue, we could make this major update offer always be visible to users who do a manual “check for update”, and only chose to make this major update offer visible to idle users at certain times.
• this would mean users who skipped over a major update offer previously (see earlier blog for details) would have improved odds of seeing *any* major update offer.
• mechanically, we could do this new major update offer at the same time as the actual new dot release, but I think it makes more sense to wait a few days just to make sure there are no respins/zerodays.

3) Offer major update for multiple dot releases
Historically, we only provide major update offers from latest dot release because:

• it has the most users
• they are already shown to care about updating and
• thats all we had time to generate and test updates for.

However, mechanically now that we have streamlined the process, we can now also cherry pick some other dot-releases to provide major update offers for at the same time. For example, we could provide major updates
for the top three most populated dot releases (today that is FF2.0.0.20, FF2.0.0.18 and FF2.0.0.14) at the same time. However, some concerns are:

• this takes some extra work in RelEng, and has more significant testing load on QA, so how often this is even possible depends on other work at the time.
• the users still on FF2.0.0.14, FF2.0.0.18 have already said “no” to minor updates for FF2.0.0.19, then FF2.0.0.20, so its not clear how many would accept a major update offer.

4) Change the major update dialog

Changes to the update system are always scary, and slow to roll out, because we have to wait an entire product release cycle. However, while they are kinda beyond the scope of this blog post, I wanted to raise two suggestions here:

• Right now, when a user gets a major update offer, and clicks “Later”, that actually means “no and don’t ask me again until you create a new different major update offer”. What if we changed the client updater as follows:
• Rename the “Later” button to “Not this time”; no change in functionality
• Add a new “Ask me again when I next start/exit” button, which would find what major update offer was available on next start/exit of browser, and re-prompt the user.
• or maybe simpler to change the “Later” button functionality to ask user again on next start/exit, and not add a 4th button?
• In a recent brainstorming session with beltzner one Friday night, another possible enhancement was to track when the user sees a major update offer, and don’t re-prompt that user for another major update offer within ‘n’ days of the last major update offer that user saw. This would help address the user skipping over major updates, and also prevent user-update-fatigue concerns.

Hopefully those scenarios all make sense. There’s been a lot of behind-the-scenes plumbing improvements over the last 18months, so hopefully these blog posts help raise awareness for some new options that are now mechanically possible.

UPDATE: Added dialog box screenshot, along with suggestion of changing functionality of existing “Later” button. John 10mar2009