Hi Phillip,
I don't have answers to all of your questions, but here are some high
level end user requirements as I understand them:
(1) We need to provide a path for users to migrate their data from one
release to another. This includes 0.6 --> 0.7.
(2) For 0.6 (and 0.6.1) --> future releases, we only need to provide
this path for calendar data, not all data persisted in the repository.
The currently available mechanism is to export the data to (standard)
ics files, and then to reimport.
(3) In the 0.7 timeframe, we're going to have midpoints (maybe these are
the same as milestones, full proposal coming) that the user can download
and use. This implies that we need to support a path for users to
migrate data from 0.6.1 --> 0.7m1, from 0.7m1 --> 0.7m2, etc.
(4) In the 0.7 timeframe, we need to expand the set of data that needs
to migrate beyond calendar, to include notes and other items seen in the
"dashboard". We do *not* need to support all persistent data in 0.7. We
do probably need to support some calendar preferences and account
settings. We don't need to support migration of ui settings (most cpia
persistent data).
(5) By 1.0 we'd like to be able to preserve "presentation data" across
releases as well.
(6) Before 1.0, we ask users to live with some risk of losing their
data, though we make it a high priority now to fix any bug or problem
known to cause data loss or corruption.
(7) The install process or Chandler launch should automate some of the
upgrade process in 0.7 (instead of asking users to do this by hand as we
do now).
(8) There should be some path for extension parcels to have data
migrated along with the ootb schemas, but it can require extra work from
the parcel writers to make it happen.
We have some open questions around sharing and schema evolution.
- Do we need to support multiple chandler versions sharing the same data?
One sort of ugly short-term proposal that Morgen and I discussed: users
would have to migrate their data locally and then publish a new share to
the server (new tickets, new subscriptions for sharees, etc.)
Morgen and I agreed that in the long term, we probably need to identify
a sharing format (the well defined externalization of the data that you
mention). This would allow the client (and the server) to be able to
change internal formats, as long as they could migrate the data to the
well known externalization. This would require some work in the sharing
framework.
Morgen proposed that the 0.7 release be the release that we really nail
down the domain model as well as this externalization. This would mean
him spending some time on the sharing framework to support this, which
we believe would fit in the schedule.
More comments below...
Phillip J. Eby wrote:
At some point, Chandler is going to be keeping users' real data, and be
the only place where that data is kept. When that happens, we will be
responsible for ensuring that their data remains intact across
upgrades. Even if this is done through some kind of import/export
mechanism, we will need to keep track of the changes in our schema so
that this *can* be done.
There are several key questions about this that remain open:
* When will we be committing to keeping users' data safe across
upgrades? Is it 0.7? 0.8? 1.0?
See above. Ask more questions if you need clarification. :)
* How will we ensure (procedurally or otherwise) that each version of
Chandler will successfully upgrade from older versions?
I'm not sure I fully understand this question. Is this question about
testing?
* What support will we provide for parcel developers to ensure that
*their* schemas upgrade safely, as well as the Chandler "out of the box"
schemas?
I think that we need to provide hooks so that parcel developers can hook
into the same ui. If we ask the user to do a manual step to
export/import, the parcel developer should be able to get data into that
same exported file (or directory or whatever). If we have an automated
step at startup, the parcel developer should be able to take advantage
of that same automated step.
I think it reasonable to ask the parcel developer to do some work,
define an external format, etc.
* When an upgrade has to be reverted, what guarantees should we give the
user for being able to revert safely without losing data?
Is it reasonable to assume that a backup externalization is good enough?
While I'm taking responsibility for driving the technical implementation
of schema evolution features in 0.7, there is a lot here that is more on
the organizational commitment level. Really, the technical
implementation of schema evolution features is only the tip of the
iceberg of effort here. Tracking changes, writing upgrade code, and
testing will be the biggest resource investments here.
Agreed.
Cheers,
Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
