If a downgrade is detected, i.e. db version in code < version stored in code, the application is blocked.
This happens when the code is upgraded, causing a db upgrade (#27), then the code is rolled back to a previous version. Typically, this would happen if a the new version is affected by a critical bug and we need to rollback to the previous version.
In this case, the application refuses to run because the code version is lower than the version stored in db.
The only way to resolve this is to:
either re-deploy the new code, which in this scenario is not acceptable
or modify the version stored in database to set it back to a value lower to the code which essentially tricking the code to believe that the db has the structure it expects. This will however most probably cause a problem during the next upgrade when the upgrade script tries to modify the db structure e.g. try to create a new table/column that already exists.
With this issue, when such a situation is detected, the page will propose a list of possible backups to restore, so that the db is rolled back to a version compatible with the code.
In combination with #78, we should always be able to rollback to the situation before the new code was deployed.
If a downgrade is detected, i.e. db version in code < version stored in code, the application is blocked.
This happens when the code is upgraded, causing a db upgrade (#27), then the code is rolled back to a previous version. Typically, this would happen if a the new version is affected by a critical bug and we need to rollback to the previous version.
In this case, the application refuses to run because the code version is lower than the version stored in db. The only way to resolve this is to:
With this issue, when such a situation is detected, the page will propose a list of possible backups to restore, so that the db is rolled back to a version compatible with the code.
In combination with #78, we should always be able to rollback to the situation before the new code was deployed.