The flawed update mechanism
Perhaps you remember the 1.0.8 update a couple of weeks ago. While it certainly solved bugs and misalignments for many, it also resulted in quite a number of reports about messed up shops after the update. That's not tolerable, of course.
Thinking about this problem I compared to what we developers do to switch between versions, and why we pretty much never mess up a shop installation by doing so, despite switching back and forth all the time. Developers do a git checkout 1.0.7 to switch to version 1.0.7, git checkout 1.0.5 to switch to version 1.0.5, git checkout 1.0.x to switch to the latest development, and so on. And there's the fundamental distinction: doing such a checkout doesn't apply a patchset or a set of changed files, like the current updater module does. When checking out a version, Git compares files currently on disk with kind of a master set of files (stored in the .git directory), then changes files on disk to make them match this master set.
The current update module, which is a refined version of Prestashops 1-click updater, has a fundamental flaw: it doesn't check whether files on disk are right, but blindly applies a set of changed files. Who creates this set of changed files? Right: thirty bees developers, which have never seen your shop installation. This set of changed files gets created not on knowledge, but on assumptions. The assumption that your shop installation matches a clean shop installation. Which is often not true, as we unfortunately experience over and over again.
Having the fundamental flaw detected, a new updater module started to evolve. Prepared sets of file changes are gone. Instead, the module compares the shop installation to a clean master installation, which gets served by api.thirtybees.com. This always works, and after an update, a shop will always be in a clean, sane state. A recipe for reliability.
This works from any release to any release. Select the wanted version, click Compare and see which files changed since then.
Which means, one can downgrade or rollback just a easily as update.
Another use case is to compare the current installation to the master installation. Updating from e.g. 1.0.8 to 1.0.8 is perfectly possible, to restore a broken shop.
Before too long, this will also support updating to development branches. E.g. to test bug fixes provided on Github. Or even single commits.
Manual changes get detected. During comparison, the module detects files which don't match the original version, so the merchant can deal with his manual edits.
Smooth operations. All operations taking place got split into small chunks, so one can virtually never run into maximum processing time limits.
Here it is:
Install it by unpacking in the modules folder or using Add a new module (top right corner) in back office -> Modules & Services -> Modules & Services.
Having the module installed, a new menu item, Updater, appears in menu Preferences. That's where this module gets controlled.
Yet To Do
Actual updates. Currently the module does comparisons only, not actually change files. Which is why playing with this module preview is safe.
File filtering. Some files should get ignored. For example, an update shouldn't reinstall the install/ folder despite this folder being present in a clean installation. It also shouldn't remove product images or translations, despite them being not present in releases.
User interface. Currently, this module shows a list of all changed/created/removed files. This can be a huge list with up to 10,000 lines. Ideas to display this list in a less scary way are welcome.
And for those not installing the module immediately, here's a screenshot: