Thank you, @NateWr . That would be great! 
@marc :
Is ojs_updater able to upgrade directly from 2.x to the last 3.3 version? (without an stop at 3.2 upgrade)
Yes and no! The updater can update your journal up to 3.3, but you have to make the recommended stops inbetween. In the end, the ojs_updater is only upgrading your journal to the latest version available to it (in the versions folder) and we did not want to put in any “intelligent” behaviour. The latter also because systems vary so vastly that this behaviour would probably break something most of the time.
How did you test the application? Even with multilang journals? Any know issues?
We tested the ojs_updater with both multi-language journals and single-language journals. The ojs_updater only replicates all the manual steps you would do when updating your journal. We use the ojs_updater for our production system and did not run into any issues yet.
However, this is also the downside of the ojs_updater. Although we tried to make the tool highly configurable, we do not know the server configurations of other people. There may be issues, we do not know (as it is always with software).
So, first thing you can do to make sure that everything works, is to run the tests of the ojs_updater (using pytest). Furthermore, we recommend to simply try it with a dummy journal that has comparable configurations to your production journals.
Is the script upgrading config.inc.php? What values are assumed?
No, the script only copies the config.inc.php from the old version to the new one. The ojs_updater does not touch your files at all (except for switching the installed attribute in your config.inc.php from on to off and back again after the upgrade). The ojs_updater leaves it to YOU to make sure that any (!) of your files are correct and compatible to the new version after the upgrade. This is because between OJS version so much stuff can change (I am thinking e.g. of the template version upgrade) that we would be very busy making the ojs_updater compatible to each new OJS version. We did not want this. The ojs_updater should just work with any foreseeable OJS version that has the same upgrade routine.
How do you deal with DB inconsistencies? Is the app able to apply common DB curations?
The ojs_updater does NOT check your database consistency or validity! It only makes a database dump. It assumes that your journal would not run with an inconsistent database. However, if OJS can handle the database inconsistency, the ojs_updater will (probably) work, because it does not touch the database. Hence, there is also no database curation in any way!
How did you manage to reduce the upgrade time from 20 to 2 minutes?
Perhaps it is only me, but when I manually upgrade my journals, I work very slow to make sure I make not mistakes. Make a backup of database and directory, create a new copy of the newest OJS version, copy over the public folder, copy over the config.inc.php, check that the permissions are set etc. . All these tiny things the ojs_updater does for you. It just walks along the OJS update “recipe” and puts in all the ingredients. After the OJS upgrade.php script ran, the ojs_updater is done.
How do you show the upgrade errors? Are you tracking the original ojs ones?
The on-screen logs of the ojs_updater are quite verbose (and that is only the INFO setting). Nearly every step has its own log. And yes, the OJS logs, when calling the upgrade.php, are also printed on screen.
When you integrate the ojs_updater in the docker-ojs, this would be really awesome! Please let us (either me or @thf ), when you need support.
