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@...> 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@...

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@...

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@...




--
Henry
Crowdsourcing Crisis Information

www.ushahidi.com | twitter.com/ushahidi
Ghana: +233243581806
Skype: eyedol25