Places Migration Scenarios

Need to detail the up/down/sidegrade scenarios for Places, how they're handled.

Upgrades:

from	to	action	notes
<=2.*	3.0a2	history moves to Places
3.0a2	3.0a3	some schema changes	XXX bug#s
<=2.*	3.0a4	history and bookmarks move to Places
3.0a2	3.0a4	bookmarks move to Places

Testing

We need an automated way of testing migrations:

First install, no profiles
- Test migration from each supported browser/external-app
Upgrades from major versions
Downgrades to major versions
Sidegrades between locales, partner builds, other

Also, we need to detail a policy regarding support for foward/backward/ad-infinitum support for bookmarks.

Notes on handling schema changes for bookmarks:

Bookmarks from places.sqlite will be backed up to bookmarks.html at shutdown.
For the upgrade from Places-no-bookmarks to Places-bookmarks, we'll delete and re-initialize the bookmarks tables.
For subsequent schema changes we'll write migration code.
Since SQLite doesn't allow column drops, those changes will require staging the data in a temporary table, dropping the old table, and then renaming the new table.
The dump approach can be lossy, so it's key that we evaluate the necessity of this and fix any data-loss moving forward.
Bookmarks.html is archived to the {profile dir}/bookmarkbackups directory (like Fx2).
If you downgrade from Fx3 to Fx2, you'd get any new bookmarks, as Fx2 will use the boomkarks.html file.
If you then upgrade again to Fx3, new Fx2 bookmarks are not automatically re-imported, as that only happens on a schema change. The user can import manually.
The export code needs to export and import microsummaries and livemarks, which
As far as exporting other data to avoid a lossy transition from schema x to schema y, we might write out attributes in bookmarks.html, but we need to make sure Fx2 and other browser can handle that gracefully.
We don't want to dump/import on every schema change. Only if necessary, as some (inevitable) schema changes can be done with migration code.

Bugs: