I don't expect this to be fixed, but I'm filing this bug so that others can find the workaround. If you try to run FF with a version older than the version you used last, you'll get a popup saying that doing so could result in corruption and you have to create a fresh profile. There is no provision for overriding this; FF simply won't start. This is based on information in a file called compatibility.ini which is found in ~/.mozilla/(profilename). It has a "compatibility" section and a LastVersion keyword that lists the last version of FF that used this profile. This doesn't always work. I have a pretty old cauldron system where LastVersion suddenly got set to 68.5 in spite of the fact that the system had never been updated since install. The way you fix this is to reset the major version of LastVersion to a lower number than your installed FF. Then FF will start. At that point, you can choose to export information from your profile, then restore compatibility.ini, and create a new profile into which the information can be imported. Or, you can just continue to use FF. compatibility.ini will be reset to the version you're using. This same behavior occurs with Thunderbird, and the solution is the same, except that the compatibility.ini file is in ~/.thunderbird/(profilename).
This is already annoying many people, and looks like it would cause trouble for an upgrade. Frank, can you say what versions of these programs you are using. Firefox has no dedicated maintainer, so assigning globally for that. CC'ing zezinho & ns80 as recent Thunderbird updaters.
CC: (none) => lists.jjorge, nicolas.salgueroSeverity: normal => majorSummary: Nanny firefox refuses to use older profile, requires fresh profile => Nanny Firefox & Thunderbird refuse to use older profile, require fresh profilesSource RPM: firefox => firefox, thunderbirdAssignee: bugsquad => pkg-bugs
The most recent case occurred when I booted an older cauldron partition because of the current NSS problem. The cauldron versions were 68.9 and the older versions were 68.3. In the case where the old cauldron system was affected, it was at 52.something, so this behavior has been around for quite a while. This shouldn't cause problems for an upgrade because the versions only go up (normally). I have no idea how the old cauldron system got changed. Like I said, I don't expect this to be fixed because it's obviously deliberate behavior from upstream, even if it is bad design. It should probably be closed as WONTFIX or left as NEW so that people can find it.
There is a way to go on : use --allow-downgrade on cli.
Resolution: (none) => WONTFIXStatus: NEW => RESOLVED
There is nothing bad about a design that is preventing corruption of data.
CC: (none) => rihoward1
The bad part of the design is that the GUI doesn't give you the same override that the CLI does.