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... |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
