Would be nice to give verbose feedback during upgrade of the actions being executed...

.... collecting entities

.... updating timestamps

..... cleaning up migrated entities

.... mailing the admins we finished the upgrade

Yes, I've already been planning something like that. It can however be implemented later. Currently I just need feedback about the general structure of the plugin-facing Elgg\Upgrade\Batch interface.

Do you as a plugin dev find it easy to understand and use?

It's already a big improvement to the Elgg 2 approach, where you have to write:

• Script that registers the upgrade when triggering site upgrade from admin panel
• Action that gets called during the upgrade
• Action registration call
• View that displays the upgrade

But is there something that would make the proposition even better?

@iionly you have also been maintaining a lot of plugins. Any feedback about the interface?

I think the interface looks good. It allows to display a description text and the progress getting displayed is surely helpful for long running upgrades.

Maybe in addition to the counting of successes and errors and the registering of error messages it could be very useful to add some methods to allow for creation of a log file in the data directory (<dataDirectory>/UpgradeLogs/<UpgradeClass>/run_YYYYMMDD_timestamp.log). Error messages are rather a short-term help only and might not be of much use if there are too many errors happening. A log file could be useful if something goes wrong for whatever reason and some rescue action is necessary. Matt made a contribution to Tidypics that adds a clean-up routine to find image entries without image files and this routine logs the results in such a logfile.

Is there a mechanism to stop the batch loop if some condition occurs and to marks the upgrade as not finished? For example, an update would come across a file in the data directory it needs to move but can't due to file permissions. Would it really make sense in such a case to continue (maybe with coming across the same problem again) and then maybe even mark the upgrade as finished successfully or wouldn't it make more sense to stop the execution immediately, still display this upgrade as pending and output an error message to the admin of what to do to fix the problem?

I like it that you can define dependencies between upgrades. I had the problem in Tidypics on the upgrade to Elgg 1.9 that I had to warn people to first run the pending core upgrades before running the Tidypics-upgrades but I had no way of simply preventing the execution in the wrong order.

Is it possible to use the new upgrade feature also for non-batch upgrades to have a unified upgrade mechanism for everything? I guess you could always implement a run() method even if it doesn't use an ElggBatch. But it might not make sense to display a progress bar (maybe only for a fraction of a second) if an upgrade will not take long.

How is the upgrade level of a plugin managed? If I'm not mistaken the time of sucessful execution of each individual upgrade is saved in the database. But how can you convert existing upgrade scripts into a class and let Elgg know if they need to be run or not? For example Tidypics handles the upgrade level using a "version" plugin setting that gets updated after an upgrade script has finished. So, the "Upgrade" button is only displayed if there are newer upgrade scripts in a new version of Tidypics that need to be run. If the existing scripts would be converted to classes, a pending upgrade for each of them would be displayed if there's no plugin-central upgrade level control.

It's clear and looks easy to implement, I like it