In the quest of wrapping up the 2.1.0 branch for release, I have started
to do serious regression tests in making sure that the migration for
users of piggy bank 2.0.4 is as smooth as possible.
Early on during 2.1.0 development I changed the UUID and the name of the
main XUL overlay, because I thought they were creating some issues with
firefox 1.0. The problem is that with a different UUID, firefox
considers 2.0.4 and 2.1.0 completely different things, and therefore
allows them to run in the same space.
The problem is that they both advertise themselves as "piggy-bank",
therefore the chrome://piggy-bank/ URLs confuse the browser (if you ask
em, this is a pretty serious architectural limitation of XPCOM, but
that's another story). The confusion is so deep in firefox 1.0 that the
browser stalls and no window even shows up. This requires manual editing
of one of the RDF files to clean up, not something I want our users to
go thru if they forget to uninstall 2.0.4 before installing 2.1.0 (which
is very likely to happen).
So, I tried to roll back the UUID and the overlay name to the old ones
and see if this still caused issues, and, to my surprise, it turns out
that everything works just fine. It might have been something else that
I managed to fix down the cleanup road.
Anyway good news, I have just committed a fix that unifies the UUID and
the overlay name, so that users of 2.0.4 can update with one click and
forget about it. PiggyBank will take care of the rest, including
configuration, data migration, re-indexing, popping up the toolbar
button for you to drag into the toolbar and pointing to a 'now what'
page to get you started (especially in finding the scrapers and the
information on how to write them).
The only problem is that if you are running on the bleeding edge with
the nightly built XPIs, now *YOU* have to uninstall the previous XPI
before installing a new one. Don't worry about your data, uninstalling
piggybank does *NOT* remove the data from your disk, and the new version
will pick it up as before (anyway, do a profile backup wouldn't hurt)
We warned you that we didn't commit to back compatibility of the nightly
builds, but at least this is a friendly note on how to get out of the
impasses without issues.
For the future, we are fine: we'll stick to this UUID for now on.
--
Stefano Mazzocchi
Research Scientist Digital Libraries Research Group
Massachusetts Institute of Technology location: E25-131C
77 Massachusetts Ave telephone: +1 (617) 253-1096
Cambridge, MA 02139-4307 email: stefanom at mit . edu
-------------------------------------------------------------------
Received on Thu Sep 22 2005 - 18:10:38 EDT