<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">A commendable idea, but a quick look at
my profile suggests it takes windows some 3 minutes to tell me it
is 29.9Gb in size and has 230,223 files in it. That is without
the mozEML files that we routinely also have in Windows installs.
I manually deleted well over 100,000 of those when I turned to
option off.<br>
<br>
So do we want to add such a lengthy time to "updates"? If it
takes 3 minutes to identify them I assume the backup will be
excruciatingly slow. 30Gb of data is always going to be slow
going.<br>
<br>
Having said that, there is a very real need for an inbuilt profile
backup and restore, and user demand for such an option. But I
think it needs to be a user accessible option with scheduling,
not something we try and put into the update process. Think
migration to a new device as well as just backup.<br>
<br>
Matt<br>
<br>
On 05-Jul-19 3:33 AM, John Bieling wrote:<br>
</div>
<blockquote type="cite"
cite="mid:475e83ac-e2d1-5fa2-eec5-82d43caee164@gmx.de">I really
think TB should automatically backup a user profile, when it
<br>
gets access by a higher major version number for the first time.
So in
<br>
the current situation, after the user updated to TB68.
<br>
<br>
If the user later returns to TB60, he will get the error message
about
<br>
not being able to access his profile (as it was modified by TB68)
and
<br>
instead of suggesting to create a new profile, just allow him to
switch
<br>
to the backuped version of his TB60 profile.
<br>
<br>
John
<br>
<br>
<br>
<br>
Am 04.07.2019 um 18:51 schrieb Jacques Angevelle:
<br>
<blockquote type="cite">Hi,
<br>
<br>
From user's point of view, I think downgrading is nearly
mandatory. New
<br>
versions are often broking add-ons a user can consider essential
for his
<br>
daily use and new dev. policy disabling number of add-ons is
really hard
<br>
to accept. The alternative could be difficult to implement :
warn before
<br>
installation about ALL disabled add-ons with the new version.
Backing up
<br>
all the profile is a solution but I doubt users will do this
before each
<br>
upgrade. The main repercussion should be that users will stop
upgrading
<br>
TB and this is a real security hole.
<br>
<br>
Jacques
<br>
<br>
<br>
Le 04/07/2019 à 09:30, Nomis101 🐝 a écrit :
<br>
<blockquote type="cite">Am 04.07.19 um 02:59 schrieb Ben
Bucksch:
<br>
<blockquote type="cite">Mark Banner wrote on 02.07.19 13:31:
<br>
<blockquote type="cite">was once basically "downgrades are
nice but not really supported" is
<br>
now a definite "downgrades are not supported"
<br>
</blockquote>
FWIW, downgrades have always works. I've moved between
versions of
<br>
Firefox since decades. I've never ever had any notable
corruption
<br>
(modulo very very rare bugs like bug 1530660 which were then
fixed).
<br>
<br>
This is definitely new and very inconvenient for
development, of which
<br>
testing (also with real data and old time-battered profiles)
is an
<br>
integral part.
<br>
<br>
Ben
<br>
<br>
_______________________________________________
<br>
tb-planning mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
<br>
<br>
</blockquote>
I see this exacly the same. I never found any problem while
downgrading Thunderbird. The first real issue after
downgrading I ever
<br>
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.
<br>
For beta testing and regression finding you often have to
downgrade, which is now very frustrating. And it also happens
very often
<br>
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
<br>
of any given software (because of dislike the new UI, missing
features in the new version or whataver reason). For my
oppinionen
<br>
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
<br>
to switch MOZ_BLOCK_PROFILE_DOWNGRADE off by there own risk
and defenitely warn the user before launching the new version,
that he
<br>
would not be able to downgrade afterwards.
<br>
<br>
</blockquote>
_______________________________________________
<br>
tb-planning mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
<br>
</blockquote>
_______________________________________________
<br>
tb-planning mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
<br>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
“Against stupidity the gods themselves contend in vain.”
<i>― Friedrich von Schiller, Die Jungfrau von Orleans </i></div>
</body>
</html>