Fun and Games with Major Updates (more followup)

AndersH asked an important question in comments to my last post., which deserved a proper response, hence this blog post. Thanks AndersH, sorry, I should have been more clear.

We do *today* have a major update offer visible to FF1.5.0.12 users, which will major update them to FF2.0.0.6. A user on FF1.5.0.12 who decided to move to the latest and greatest Firefox would end up going from FF1.5.0.12 -> FF2.0.0.6 -> FF2.0.0.20 -> FF3.0.5 -> FF3.0.7. Thats four updates in a row. Here’s a diagram, which shows what major and minor update offers are currently available, which might help.

The “new process” I was trying to describe above would re-generate a major update offer for the older line every time we did a minor release  on the newer line. The diagrams look simple enough…

…but the consequences are important. If we could rewind time, and had used the new proposed process, the diagram for today would instead look like this:

It would also mean that:

  • The FF1.5.0.12 user would now get to the latest and greatest by going FF1.5.0.12 -> FF2.0.0.20 -> FF3.0.7. Thats only two updates in a row, not four.
  • User would be able to see those major update offers more often, so motivated users would more often be *able* to major update.
  • Any FF2.0.0.20 users who hit “Later” on a major update offer would be reprompted with a new major update offer every time we produce a new FF3.0.x dot-release. (approx 4-6 weeks).
  • Any FF2.0.0.20 user who hit “Never” on a major update offer would never be reprompted for any new major update offer, even when we produce new major updates.

Hope that clarifies. Thanks again AndersH for the excellent question, and again, sorry for not being more clear the first time.

tc
John.

UPDATE: Thanks to nthomas for correctly pointing out that the FF1.5.0.12 major update goes to FF2.0.0.6, not FF2.0.0.4. Updated text, and diagrams. joduinn 16mar2009.

5 thoughts on “Fun and Games with Major Updates (more followup)”

  1. Having been through the four-stage upgrade process on a friend’s laptop recently, why not just offer the full file if we can’t get from the installed version to the latest version (or at least the latest train) in one step? Even after you go “FF1.5.0.12 -> FF2.0.0.20 -> FF3.0.7”, its still two steps, and eventually it’ll be 1.5.x->2.0.0.x->3.0.x->3.5.x->3.6.x and so on.

  2. It’s currently FF1.5.0.12 -> FF2.0.0.6 -> FF2.0.0.20 …, not 2.0.0.4.

    “Later” prompts you about a day later, rather than refusing the update. “Never” means don’t prompt again for this update, but the updater will prompt for the next major update.

  3. Though I know it might be a QA Headache, might be worth seeing if we can support FF1.0.x -> FF3.0.x directly. I know in-app-migrations may be hectic, but the potential still exists per users downloading 3.0.x (or 3.5.x) directly and upgrading anyway.

    My thought is if we can institute a general rule that “A user should be able to skip at least 1 major update line entirely and still have a useable profile in the end” we’d be much better off. Of course we only need to primarily care about what QA can support/test, and may need some actual infra app-side (and server-side) to support the people who may not want to SKIP a line.

    In theory of course, we already have that upgrade path for much of Gecko (SeaMonkey, Thunderbird for example skipping 1.9.0 and going straight to 1.9.1 from 1.8.1 — requiring toolkit, etc. to properly migrate things)

    Come to think on it, my comment may be better expressed in a separate blog post, or an entirely new thread on .planning, but here will suffice for now.

  4. I fully agree with Callek that we should even go as far as to offer direct updates to at least a supported version right away, even for FF 1.0 and 1.5, as offering people a major upgrade that just goes to another unsupported product like FF 2.0 is probably still bad.

  5. My point was, that if the update UI was changed so only a single dialog was shown to the user, it would look like a single update even if it in reality was four updates running and migrating data. This means that you could get all the benefits you list, without doing new QA work on the old code (which no developers are dogfooding anymore).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.