TODO: New updater

[VicDeo]

Postponed from 9.0

• upgrade:backupData Backup data (optionally)
• upgrade:backupDb Backup DB (optionally)

done with single occ upgrade invocation:
- [ ] upgrade:preUpgradeRepair Repair and cleanup (pre upgrade, DB collations update, ..)
- [ ] upgrade:dbUpgrade db schema upgrade
- [ ] upgrade:postUpgradeCleanup repair and cleanup step 2 (online) [danger, might take long]
- [ ] upgrade:postUpgradeRepair repair and cleanup step 1 (post upgrade, repair legacy storage, ..) [danger, might take long]
- [ ] upgrade:updateConfig update config.php

[karlitschek]

I think not having a db backup is ok. Maybe we should still have the step in the updater which basically says: 'and now please do amanually a db backup'
Not sure what you mean with the other steps. They are implementd in occ but will be called by the updater, right?

[VicDeo]

@karlitschek Right now occ upgrade performs all these steps at once.
Splitting occ upgrade into smaller pieces will be done when the application is ready

[karlitschek]

What do you mean with 'application ready'? Making this steps executable independently was one of the main goal for the new updater.

[PVince81]

• add more steps from the upgrade command
  • disable third party apps
  • enable new bundled/shipped apps

[PVince81]

• update steps for every app ? (appinfo/preupdate.php, appinfo/update.php), might need better API to be able to get feedback from app's updates

[PVince81]

Ideas:

• add more feedback on schema migration:
  • which SQL statements will be executed as part of the schema diff
  • count entries of each affected tables and compute a possible time estimate about how long it will take (it's fine if we say it takes a day even if it's much shorter)

[VicDeo]

@PVince81

Update steps for every app ?

I'd vote for step by step migrations based on doctrine/migrations (as a long-term goal)
e.g.

genericAppId/appinfo/setup/install-1.0.0.0.php
genericAppId/appinfo/setup/install-1.1.0.0.php
genericAppId/appinfo/setup/update-1.0.0.0-1.0.0.1.php
genericAppId/appinfo/setup/update-1.1.1.2-1.1.1.3.php
genericAppId/appinfo/setup/update-1.1.1.4-1.1.1.5.php
genericAppId/appinfo/setup/update-1.1.2.1-1.1.2.2.php
genericAppId/appinfo/setup/update-1.1.3.2-1.1.3.3.php
genericAppId/appinfo/setup/update-1.1.3.6-1.1.3.7.php
etc

With the following logic:

• missing genericAppId/appinfo/setup/ dir means that legacy migration will be used
• missing update file means 'there is nothing to change in DB/settings, just increase the version'

On install:

• choose closest install.php to the version that is going to be installed
• apply all update-*.php inbetween version from install.php and actual version

On update

• apply all update-*.php inbetween current and new version

In this case there is no need to perform additional version checks in the app.

[ruddyconsult]

@VicDeo
Please advise on my situation already described to you once separately. Reminder: I tried to restore my most recent updater-backup 8.2.3.2 after an incident that took my Owncloud offline. It didn't suffice. Should I continue with older updater-backup copies, or alter the config.php file somehow?

[PVince81]

@VicDeo please update the checkboxes

[PVince81]

@VicDeo please update the checkboxes

[PVince81]

asked on IRC, he said "nothing to update according to #304"