Repository navigation
Owncloud migration documentation: Add hints to edit version.php, and to trigger background migrations after each upgrade step #13109
Description
Activity
- changed the title
[-]Owncloud migration documentation: Add hint to trigger background migrations after each upgrade step[/-][+]Owncloud migration documentation: Add hints to edit version.php, and to trigger background migrations after each upgrade step[/+]on May 6, 2025 Regression from #13026
Synology has relased a new version of the DSM System (7.3) which does not support PHP7.4 anymore. So maybe many other users need to switch from owncloud to nextcloud which still used owncloud as ist worked a long time with the webstation on synology.
Maybe the documentation could be updated so other users do not need to search for the workaround for that problem.Why will it not fixed? I think it is a simple step to write it into the documentation? I had struggled much time with this issue until I find this out. A small passage about to change the version from
'version' => '10.16.1.0',to'version' => '10.13,'in the config.php will save a lot of trouble and time.
The Owncloud migration documentation is helpful and mostly works, but it is missing two crucial hints:
The migration documentation advertises compatibility with Owncloud versions 10.13.x, 10.14.x, and 10.15.x, but only works out of the box with Owncloud version 10.13.x.
The reason is that Nextcloud 25.0.13 declares itself compatible with Owncloud 10.13.x only in version.php. Changing this file allows the migration to proceed.
As it's impossible to file bugs against this unsupported old Nextcloud version, the migration documentation should explain how to change the version.php file.
As documented in How to upgrade, we must wait for all background migrations to complete before taking the next upgrade step.
The Owncloud migration documentation neither advises to pause and wait for background migrations to happen (or to trigger them manually), nor does it link to the latter page that explains the matter. Thus, it's easy to miss when going through the 25 → 26 → 27 → 28 → 29 → 30 → 31 upgrades. This is in fact what happened to me during a recent upgrade: Several background migrations were missed or aborted, leading to an inconsistent database schema.
I suggest adding an explicit hint to the migration documentation.