Consider that new SavaPage versions sometimes need a database schema update. This involves executing an SQL script, before running the new version.
Beware that update.sql scripts must be executed in the right order. So, when SavaPage is updated from version A to C (skipping version B), this implies that both the A-to-B.sql and B-to-C.sql update scripts must be run.
Also, it is good practice to back-up the database before executing any update.sql script.
Although SavaPage is prepared for automatic DB schema updates (and making a database backup before the update), I did not make use of it yet, and chose to make the sysadmin execute the upgrade.sql scripts manually.
This strategy is motivated by the fact that auto DB update introduces considerable overhead, as each schema version needs to be represented in the SavaPage installable. And, as repeated DB changes were envisioned, the extra work involved for each iteration was disproportionate.
As the database schema is more stable now, activation of auto DB update is certainly an option. This would of course imply a significant programming and test effort at the next DB schema change.
At least at the introduction of the SavaPage module, I advise to use “Stable approach”. In that way you have optimal control, user protection, and you can script upgrade.sql and database backup as needed. Depending on rate of deployment and community member reactions, we can decide on how to proceed next.