[Chandler-dev] Data Migration/Installers for 0.7

Sheila Mooney sheila at osafoundation.org
Tue Jun 27 10:35:32 PDT 2006


Context:

For some time, providing a better data migration strategy and path  
has been part of the 0.7 goals. When we started planning, this meant  
facilitating the ability for our 0.6 or 0.6.1 users to migrate their  
calendar data into 0.7. We are ultimately thinking about how we want  
things to work at the end of 0.7 and know that the migration path  
from Alpha to Alpha release is still a bit up in the air depending on  
where we are in the process. Up until now, we have been addressing  
this on a per release basis by providing some path, even if it's just  
a manual one.

What's changed:

Now that 0.7 is further along, a few things have changed.

+ 0.7 is now going to be our Beta release which means extending 0.7  
beyond what we thought the original goals were.
+ Significant features such as the dashboard will be introduced  
during 0.7 and we will be actively encouraging users to try these out  
before the release. This means that people will have more than just  
calendar events in their repository.
+ With some of the changes we are making, particularly performance  
work, background sync etc, most of our users will likely upgrade to  
one of the interim 0.7 alpha releases and we assume there won't be  
very many people migrating from 0.6 to 0.7.
+ We have spent most of our time thinking about what happens when I  
upgrade by Chandler. When we recently experienced an upgrade (and  
data wipe) of the Cosmo Demo server the feedback we received is that  
it was cumbersome to re-establish all our shares and get our Chandler  
working again. This is kind of an additional data migration use case  
that we didn't think of.


For users installing new versions of Chandler:

+ We will likely worry less about the users going from 0.6 -> 0.7  
since the manual path will exist (export calendars, reimport etc).
+ The way we are thinking about the requirements is not about 0.6 ->  
0.7 but how we want to migrate to the Beta version which perhaps  
implies doing a bit more.
+ We will focus on the go forward scenarios, meaning that we will  
have a plan for some migration of an alpha release ie: Alpha4 -> 0.7.  
We don't yet know how many milestones we will have until 0.7. Whether  
or not and how we support Alpha4 -> Alpha5 -> 0.7 is undetermined.
+ We would like to be able to backup more than calendar events ie:  
tasks, mail, stamped items.
+ If possible we would like to be able to migrate other things like  
account settings and what collections we have in the sidebar, what  
were shared or subscribed to, item membership etc
+ The ideal solution would be that when you download a new version of  
Chandler and launch the new app, we would detect if the user has an  
old version and attempt to suck down the data and the account  
settings and restores a user's sharing world.
+ The PPD team has discussed alternatives ie: a menu item to back up  
your stuff but It's probably easiest to start the conversation around  
the ideal solution.
+ Another possibility is to distinguish between a first time install  
and a subsequent install to help users setup their accounts. This is  
not really a Beta goal but might be considered for 1.0.

For users running an existing Chandler against a server after the  
data has been wiped:

+ This is difficult since there is no way to reuse existing tickets.  
The user has to republish and obtain new tickets for the shares they  
have subscribed to.
+ We could consider a way to automatically republish the shares in  
one step but all the urls would still have to be distributed and we  
wouldn't really eliminate much work for the user.
+ There are some questions around the need to even address this case.  
After speaking with the Cosmo team, we don't anticipate having to  
wipe the data for future versions of Cosmo.
+ The right approach would probably be to not worry too much about  
this scenario and see if we have a problem. We don't have many  
options in  any case.

Questions:

1. How difficult is it to backup other kinds of data? What are the  
implications that PPD hasn't thought of.
    + Account settings
    + Collections in the sidebar - order and item membership
    + Other preferences?
    + Tasks, email etc
    + Stamped items
2. Is it too ambitious to try and do this automatically? - should we  
do something similar to now and launch a new app with a clean  
repository and have options to move your data over.
3. We would be interested to hear people's thoughts on the  
complexities of having this happen when you run the new version of  
the app - a dialog that pops up to let the user import their data/ 
settings. What are all the things that could go wrong?
4. ...I'm am sure there are other questions we haven't thought of...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20060627/8c360304/attachment.htm


More information about the chandler-dev mailing list