Ushahidi Mailing Lists

And, hopefully a way to back out of the install at each juncture.

Jim


Henry Addo wrote:
> Hi David,
>
> Thanks for the thought. Simply put, the auto upgrade process needs to 
> be reworked. 
>
> I'm thinking we emulate Drupal's upgrade process. Its much inline with 
> your idea.
>
> An overview page that describes what is going to happen. Actions that 
> needs to be taken by the user. Like doing a manual backup or an 
> automated one.
>
> After, it lists the database schema version that is going to be 
> upgraded to. This process is simply going to employ the processes you 
> listed earlier.
>
> Then it gives a log of activities that have happened. Like, the files 
> upgraded, tables, and the summary of the upgrade process.
>
> Thoughts ??
>
> On Tue, Jun 1, 2010 at 3:57 PM, David Kobia <david@... 
> <mailto:david@...>> wrote:
>
>     Hi Guys,
>     As we get closer to pushing out the 1.1.0 bug fix release, I just
>     thought I'd bring up a few points/issues for discussion.
>
>     1. We need to need to make upgrading as intuitive as possible. If
>     anything we need to emulate the 'Installation' process to make
>     everything as clear as possible. We should probably detail all the
>     files that are being replaced too instead of an invisible process.
>
>     2. Upgrading the database. I had the following ideas:
>            - Part of the upgrade process should probably include
>     dumping/backing
>     up the old schema. The system itself should include a 'Backup
>     Database' option in the Admin interface.
>            - We need to run sql upgrades separately instead of using
>     one upgrade.sql file
>            - Also should probably rename the sql upgrade files using the
>     following format, upgrade.X.Y.sql where X = current and Y =
>     upgrade_to. This way we can perform a 'For..' Loop with 'function
>     _upgrade_tables(X, Y)' until the most recent version is in place.
>
>     3. Because a lot of people make major modifications to the View files
>     we should probably make this clear in the first step. In the near
>     future the most commonly altered views should probably be in the
>     themes folder too so that an upgrade doesn't flip the look of the site
>     back to the vanilla/default look and feel.
>
>     4. Because of slow download speeds and the fact that the zip file is
>     about +2MB big, each upgrade should probably be incremental too. This
>     way we can push out small fixes quickly and easily. We can do a diff
>     between tags using this command to get only the modified/new files.
>
>            > zip /ushahidi.zip $(git diff --name-only -a 1.0.0 1.0.1)
>
>
>     Does anyone have ideas for an upgrade process we can try to emulate
>     (besides WordPress of course)... ?
>
>
>     Thanks,
>     David.
>
>
>
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~
>     List Archive: http://list.ushahidi.com/
>
>     Would you like to receive list mail batched in a daily digest
>     instead? Send a message to:
>     developers-digest-subscribe@...
>     <mailto:developers-digest-subscribe@...>
>
>     To remove your address from the list, just send a message to
>     the address in the "List-Unsubscribe" header of any list
>     message. If you haven't changed addresses since subscribing,
>     you can also send a message to:
>     developers-unsubscribe@...
>     <mailto:developers-unsubscribe@...>
>
>     For addition or removal of addresses, we'll send a confirmation
>     message to that address. When you receive it, simply reply to it
>     to complete the transaction.
>
>     If you need to get in touch with the human owner of this list,
>     please send a message to:
>     developers-owner@...
>     <mailto:developers-owner@...>
>
>
>
>
> -- 
> Henry
> Crowdsourcing Crisis Information
>
> www.ushahidi.com <http://www.ushahidi.com> | twitter.com/ushahidi 
> <http://twitter.com/ushahidi>
> Ghana: +233243581806
> Skype: eyedol25
>


-- 
Jim Cory
Horizon Mapping
http://www.horizonmapping.net
jcory17@...