This release includes a number of important security issues that had been identified by our community. We recommend that you upgrade to this version, or latest LTS, as soon as possible.
Within the previous release, we have also resolved a few known issues with the upgrade process; however, they will unfortunately not take effect until the next upgrade cycle. Therefore it is vital that if you encounter any problems while installing that you review and follow the recommended process within the SuiteDocs upgrade debugging page which can be found here
Is that absolutely required?
If you have installed a module that has a pre_uninstall or post_uninstall script, these scripts are stored in cache/upgrades/temp.
I didn’t know about that, but - note that normally this directory is already cleared out at the beginning and end of the upgrade process. The only difference is that since the code deleting it, file by file, is too inefficient for the current number of files in our packages, it breaks many installations.
This new release introduces a better deletion routine. This novelty will take effect in all steps of the upgrade except the initial system check, because it happens even before you upload the new package.
My advice to delete manually is just to make sure it happens without timeouts. It can be essential for people who have too much trash there already, due to the faulty upgrades in the recent past. But anyone whose last upgrade was a clean upgrade will find that the directory is already empty.
Are you sure you’re not confusing cache/upgrades/temp with upload/upgrades?
Unfortunately, yes, it is taken from cache/upgrades/temp.
… which means that the temp directory is not really a temporary directory.
It would make much more sense to retrieve that from upload/upgrades … but the scripts are not stored there (only the zip file and files to restore when you uninstall are stored in upload/upgrades)
there must be something else going on here. For years now, all upgrades have started by clearing cache/upgrades/temp, and have finished by clearing it again. So if you have seen those pre- and post- uninstall mechanisms working from there, I am sure they must be copying those files from somewhere else during the operation…
My guess (I don’t have time to really check this now) is that the Module Loader starts by copying this file into that temp directory, and runs them from there. So I guess there’s no reason why they can’t be deleted afterwards.
If you start with a clean temp dir, run a module uninstall, and the script files are created there, that would prove my theory…
there must be something else going on here. For years now, all upgrades have started by clearing