Why don't we just turn off MOZ_BLOCK_PROFILE_DOWNGRADE?

Mark Banner mbanner at mozilla.com
Tue Jul 2 11:31:15 UTC 2019

On 02/07/2019 04:16, Geoff Lankow wrote:
> I digress. My point is: why do we have this thing at all? Is there a 
> good reason we want to go to these lengths, other than Downgrading Is 
> A Bad Idea™? It can be removed with a one line config change 
> <https://searchfox.org/comm-central/rev/679db3c87c1a356a66433d6c2adf6fca1f20789f/mail/moz.configure#75>.
For Firefox, the main point was to stop users "shooting themselves in 
the foot". Various items, especially the databases, can't easily be 
downgraded. For example, I'm pretty sure if you downgrade from the 
latest Firefox to ESR 60, and you'll find all your history gone, and 
potentially other things like passwords or form history. Bookmarks 
generally get recovered as there's a separate backup mechanism for that 
for other reasons.

This doesn't necessarily just happen from the latest to an older 
release, but also from one version to the next.

Whilst I can understand that sometimes users might want to try a 
downgrade to a previous version, before now, they just ran the risk of 
loosing data. Now Firefox stops this happening.

 From a developer perspective it is also nicer - what was once basically 
"downgrades are nice but not really supported" is now a definite 
"downgrades are not supported", which allows us to be more flexible 
about what changes we do and when they occur. As an example, previously 
we might have batched up downgrade affecting items so that a set 
happened on one release - now we can spread them out for whenever they 
are ready and it doesn't matter so much.

For Thunderbird it is potentially worth keeping it, for some of the core 
items such as passwords, but also in case there's changes to the mail 
storage format, or other things (preferences?) that might cause dataloss 
on a downgrade.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20190702/26b8bb4b/attachment.html>

More information about the tb-planning mailing list