Why don't we just turn off MOZ_BLOCK_PROFILE_DOWNGRADE?

Geoff Lankow geoff at thunderbird.net
Fri Jul 5 03:29:55 UTC 2019

You, and a lot of others here are missing something: *downgrading to 
version 60 is not being prevented* any more than it has been in earlier 
versions. The warning message in question only applies to downgrades 
from future versions that do not exist yet, to version 68 or later.

Future versions may very well irrevocably change things in a user's 
profile which will render it broken in current versions. We /should/ 
really be talking about making sure a user knows this /before/ 
upgrading, and can make an informed decision then. However, what's in 
front of us right now is a warning message that we have because it was 
added to Firefox, and this discussion is what to do about it.


On 5/07/19 06:03, John Bieling wrote:
> I really think TB should automatically backup a user profile, when it
> gets access by a higher major version number for the first time. So in
> the current situation, after the user updated to TB68.
> If the user later returns to TB60, he will get the error message about
> not being able to access his profile (as it was modified by TB68) and
> instead of suggesting to create a new profile, just allow him to switch
> to the backuped version of his TB60 profile.
> John
> Am 04.07.2019 um 18:51 schrieb Jacques Angevelle:
>> Hi,
>>  From user's point of view, I think downgrading is nearly mandatory. New
>> versions are often broking add-ons a user can consider essential for his
>> daily use and new dev. policy disabling number of add-ons is really hard
>> to accept. The alternative could be difficult to implement : warn before
>> installation about ALL disabled add-ons with the new version. Backing up
>> all the profile is a solution but I doubt users will do this before each
>> upgrade. The main repercussion should be that users will stop upgrading
>> TB and this is a real security hole.
>> Jacques
>> Le 04/07/2019 à 09:30, Nomis101 🐝 a écrit :
>>> Am 04.07.19 um 02:59 schrieb Ben Bucksch:
>>>> Mark Banner wrote on 02.07.19 13:31:
>>>>> was once basically "downgrades are nice but not really supported" is
>>>>> now a definite "downgrades are not supported"
>>>> FWIW, downgrades have always works. I've moved between versions of
>>>> Firefox since decades. I've never ever had any notable corruption
>>>> (modulo very very rare bugs like bug 1530660 which were then fixed).
>>>> This is definitely new and very inconvenient for development, of which
>>>> testing (also with real data and old time-battered profiles) is an
>>>> integral part.
>>>> Ben
>>>> _______________________________________________
>>>> tb-planning mailing list
>>>> tb-planning at mozilla.org
>>>> https://mail.mozilla.org/listinfo/tb-planning
>>> I see this exacly the same. I never found any problem while 
>>> downgrading Thunderbird. The first real issue after downgrading I ever
>>> had was MOZ_BLOCK_PROFILE_DOWNGRADE. For a test I downgraded from TB 
>>> 68 to 60 and even to 45.8, but could't see anything broken.
>>> For beta testing and regression finding you often have to downgrade, 
>>> which is now very frustrating. And it also happens very often
>>> that a normal user is downgrading. I'm in a Mac user forum and a lot 
>>> of support questions there are regarding downgrading to an older 
>>> version
>>> of any given software (because of dislike the new UI, missing 
>>> features in the new version or whataver reason). For my oppinionen
>>> MOZ_BLOCK_PROFILE_DOWNGRADE will give a lot of support questions an 
>>> a lot of angry users. At least we should give the users a possibility
>>> to switch MOZ_BLOCK_PROFILE_DOWNGRADE off by there own risk and 
>>> defenitely warn the user before launching the new version, that he
>>> would not be able to downgrade afterwards.
>> _______________________________________________
>> tb-planning mailing list
>> tb-planning at mozilla.org
>> https://mail.mozilla.org/listinfo/tb-planning
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20190705/21f14247/attachment-0001.html>

More information about the tb-planning mailing list