Currently the upgrade process checks the build ID against confluence.cfg.xml to see whether the user is trying to upgrade. In addition, the build number stored in the database should be checked to prevent problematic upgrades.
Customers might inadvertently do the following while trying to upgrade Confluence:
- Install latest version distribution
- Create new database
- Run through setup wizard
- Restore sql dump from old version
The procedure is completely broken because it loses all information stored in the home directory (such as attachments), but Confluence doesn't currently do anything to prevent it.
At the moment, the upgrade process does not start because the home directory version number (in confluence.cfg.xml) matches the build number stored in the application itself. The application starts up with the old data, and with a reindex it can look as if Confluence is mostly working. Only much later can the failure of some operation with the home directory data expose the upgrade as a complete disaster.
If the upgrade process also checked the version number stored in the database and stopped Confluence starting if the home directory and database didn't match, it would make this situation easier to diagnose and prevent customers using Confluence after such a failed upgrade.