Upgrading is not an easy difficulty for us to conquer - we can't unfortunately wave a wand and make it disappear. To tackle it, we've had to take a number of simultaneous approaches:
- improve the ocPortal documentation, and the guidance for each specific upgrade
- improve the ocPortal architecture to be more clever with respect to overrides (as these are the biggest headache when performing an upgrade)
- improve the upgrader, to better evaluate the versioning for all the code files that drive an ocPortal website
We have actually been improving the documentation and guidance since version 2.6 was released, by improving the upgrade tutorial, by streamlining our own upgrade packaging process, and improving the information our server gives out to ocPortal Admin Centres indicating whether an upgrade has been made and what the changes are. Users have benefitted from this since version 2.6.1. Our improvement to documentation is that we have really reviewed the whole philosophy of versioning from a business perspective and created a clear written brief on how we support old versions, how we make new ones, and how we handle emergency situations like security vulnerabilities and stability errors.
Improving the architecture of overrides was a real challenge. For those who aren't aware of the core problem being faced, it is roughly as follows:
- A user installs ocPortal for their website
- The user customises (overrides) a template (for example)
- The user performs an upgrade, but the original version of the template they modified is now different, and ocPortal is stuck with a dilemma that it can not resolve: which is the best version?
There realistically is no ideal solution, but we have been able to mitigate it greatly. ocPortal will now record the origin of any kind of override performed from within it, and the upgrader will then look at that origin and clearly spell out the problem, with detailed resolution details.
Some of our more experienced users might suggest 'Diff' functionality, but anyone experienced in trying to upgrade something like 'Gentoo Linux' configuration files will know that that can just make things far more complex for the average user.
Another dilemma is as follows:
- A user has an ocPortal website
- The user wants to perform a major upgrade
- The major upgrade is such that some ocPortal files on their website from their previous version should no longer be there
The improved upgrade system fits together with our new addon system, which is based on the old 'modification' system. The addon system has everything the old modification system had but now also has the potential to:
- uninstall addons
- store addon dependencies
Tomorrow we'll be announcing special help for those of you who feel insecure.