Steps to reproduce
- Start with any Owncloud version that's document as being migrateable in the migration document, but is not in the current release's current
version.php file's VersionCanBeUpgradedFrom.
- Run migration either using the automatic migration tool or the steps in the migration document
- Realize the documents weren't accurate and cry noisily into your beer because you now need to restore your database and all of your files. (Or alternately manually edit
version.php, which I did because I verified it was safe to go from 10.0.8. But I shouldn't have.)
Expected behaviour
When the migration tool starts, it should access the version.php file and check if this will be a permissible upgrade path before it clobbers the database or the local /var/www/owncloud directory.
Actual behaviour
When the migration tool starts, it migrates the database and the local /var/www/owncloud directory. Then, at the end, it checks to see if this is permitted and throws an error if it wasn't. This forces users to have to recover the database dump and the files from a backup directory, and restart a fairly complex process.
Steps to reproduce
version.phpfile's VersionCanBeUpgradedFrom.version.php, which I did because I verified it was safe to go from 10.0.8. But I shouldn't have.)Expected behaviour
When the migration tool starts, it should access the version.php file and check if this will be a permissible upgrade path before it clobbers the database or the local
/var/www/ownclouddirectory.Actual behaviour
When the migration tool starts, it migrates the database and the local
/var/www/ownclouddirectory. Then, at the end, it checks to see if this is permitted and throws an error if it wasn't. This forces users to have to recover the database dump and the files from a backup directory, and restart a fairly complex process.