Andi Vajda wrote:
On Fri, 19 Oct 2007, Heikki Toivonen wrote:
Reid Ellis wrote:
Ideally, Chandler would check for updates, and when it finds there is
one:
* ask the user if they want to upgrade
* if so, the new Chandler is downloaded
* data is backed up
* the new Chandler launched with flags(?) to load the backed-up data.
That works fine if the user is managing the Chandler installation
manually. However, that won't work for packaged distributions once
Chandler goes into the repostories and users install it with a package
manager. There won't be upgrade check in a packaged application, because
the upgrade is handled by the package management system.
Neither Mac nor Windows are affected by this. It seems to me that having
installation/upgrade/migration paths that reflect the realities of each
platform we support is a must.
actually the package systems allow for pre and post install steps where
we can run export routines (in the pre) and then run import routines
in the post install.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
