Update not working properly (by design)

Ben Bucksch ben.bucksch at beonex.com
Wed Mar 9 12:59:56 UTC 2011

On 07.03.2011 15:03, Mark Banner wrote:
> On 07/03/2011 13:34, Ben Bucksch wrote:
>> I quickly found that she was still using TB 3.0. That already is 
>> major FAIL. Why's that happening?
> All users on a branch will get automatically updated to the latest 
> version if:

The latest version of the branch, right?

>     * They have update checking and automatic updates turned on (which
>       is default)
>     * They have the appropriate access to alter the Thunderbird files
>     * They restart Thunderbird to obtain the update (after automatic
>       update, although it does prompt them after a while)
> I believe that if you require admin permissions for updates, then 
> prompting non-admin users only started in the 1.9.2 branch (3.1), but 
> I may be wrong there.
> If she satisfies those options, and is still not receiving automatic 
> updates, then it should be treated as a bug and investigated as such.
>> Worse, I asked her to go to Help | Update..., it downloaded and 
>> installed the update. We tried again, it again didn't work. I checked 
>> the version again, and it was 3.0.10 - a higher version than before 
>> (3.0.3 or something), but still 3.0!
>> Why is this broken updater updating to an EOLed release?
> Due to the way updates work, and the required testing matrix, a user 
> that is on one security branch typically has to update to the latest 
> release on that branch before upgrading to the latest major release.

That may be reasonable, if you assume automatic *and* constant updates.

It totally fails, if
a) automatic update fails and the user or the "local computer guy" tries 
to update later, like in my situation with my friend. If I *manually* 
update, I want the very latest.
b) this is a machine which is not regularly used. For example, many of 
my VMs are not run for months. I want them automatically updated to the 
latest version, including the latest major version, directly.

I will *not*

   1. update FF 3.5.1 to FF 3.5.22, including
         1. Help|Update
         2. wait for download
         3. click to restart
   2. then update FF 3.5.22 to FF 3.6.17, including
         1. Help|Update
         2. wait for download
         3. click to restart
   3. then update FF 3.6.17 to FF 4.0, including
         1. Help|Update
         2. wait for download
         3. click to restart

That's totally ridiculous. If I say "update", and I end up at 3.5.22, 
although the newest is FF 3.6.17 of FF 4.0, I conclude that the update 
is simply broken, because it didn't do what I say, and it's not 
realistically doable.

I will just go to the website and download the new EXE. Which is total 
FAIL for the update function. And also is a security-problem, because a 
new EXE means a new trust-anker, an opportunity to MITM me.

I understand the test matrix concern. Why can't the updater, when it 
sees that the latest version is another major branch, just fetch a full 
package (no binary diff) and install that? I thought it already does 
that, and if so, I don't understand the problem. Testing-wise, it's 
equal to a new download.

If necessary, just download the normal installer EXE, verify it, and run 
the normal installer in update mode.
(I've written updaters myself before, and this last method is fairly 


More information about the tb-planning mailing list