Wiki source code of Simpler Upgrade (9.x)
Last modified by Vincent Massol on 2024/02/26 17:53
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | {{toc start="2"/}} | ||
| 2 | |||
| 3 | (%class="row"%)((( | ||
| 4 | (%class="col-xs-12 col-sm-6"%)((( | ||
| 5 | Requirement: investigate how we could make the upgrade experience simpler | ||
| 6 | |||
| 7 | Problems: | ||
| 8 | * File system configs that need to applied | ||
| 9 | * If extension pages have been modified the DW process can be a lengthy and advanced process in order to do the merging | ||
| 10 | * The upgrade usually is done externally (not from the running application), while the server is offline. It is very complicated to upgrade the system while it's running | ||
| 11 | * Some upgrade steps might differ depending on the OS | ||
| 12 | ))) | ||
| 13 | (%class="col-xs-12 col-sm-6"%)((( | ||
| 14 | |||
| 15 | ))) | ||
| 16 | ))) | ||
| 17 | |||
| 18 | == Ideas - Documentation == | ||
| 19 | |||
| 20 | * We can improve the documentation for each of the OS and types of upgrades | ||
| 21 | |||
| 22 | == Ideas - UI == | ||
| 23 | |||
| 24 | === Notifications === | ||
| 25 | (%class="row"%)((( | ||
| 26 | (%class="col-xs-12 col-sm-4"%)((( | ||
| 27 | * Notify the Administrator that a new version is available (use Notifications system) | ||
| 28 | ))) | ||
| 29 | (%class="col-xs-12 col-sm-4 col-sm-offset-4"%)((( | ||
| 30 | {{gallery}} | ||
| 31 | image:notifications.png | ||
| 32 | {{/gallery}} | ||
| 33 | ))) | ||
| 34 | ))) | ||
| 35 | |||
| 36 | === Extensions - Updater === | ||
| 37 | |||
| 38 | (%class="row"%)((( | ||
| 39 | (%class="col-xs-12 col-sm-4"%)((( | ||
| 40 | * Have a dedicated Administration section (either in EM or in the main category) where the Admin can see the current version of XWiki (since the footer info might be modified), and in case there is a newer version, have an "Upgrade" button | ||
| 41 | * Separate the Upgrade mechanism in Distribution and Extensions | ||
| 42 | * Propose also some buttons to "Backup" the content / database | ||
| 43 | * If hitting on that button the wikis is put in a read-only mode | ||
| 44 | * the user is presented with a "loading animation". In case the user would refresh the page, he would see that the server is actually off-line. This "Upgrade" button actually launches an upgrade process/type | ||
| 45 | * After some time, propose the user to restart the server (similar to what browsers do when upgrading) | ||
| 46 | ))) | ||
| 47 | (%class="col-xs-12 col-sm-4"%)((( | ||
| 48 | Before | ||
| 49 | |||
| 50 | {{gallery}} | ||
| 51 | image:before_state1.png | ||
| 52 | image:before_state2.png | ||
| 53 | {{/gallery}} | ||
| 54 | ))) | ||
| 55 | (%class="col-xs-12 col-sm-4"%)((( | ||
| 56 | After | ||
| 57 | |||
| 58 | {{gallery}} | ||
| 59 | image:state1.png | ||
| 60 | image:state2.png | ||
| 61 | image:backup.png | ||
| 62 | image:after_theme_state2.png | ||
| 63 | {{/gallery}} | ||
| 64 | ))) | ||
| 65 | |||
| 66 | ))) | ||
| 67 | |||
| 68 | (%class="row"%)((( | ||
| 69 | (%class="col-xs-12"%)((( | ||
| 70 | == Ideas - Implementation == | ||
| 71 | ))) | ||
| 72 | |||
| 73 | (%class="col-xs-12 col-sm-3"%)((( | ||
| 74 | === A. Core EM === | ||
| 75 | |||
| 76 | Have a Core EM, much simpler that is running all the time in the background. When upgrading, just upgrade the UI and the extensions. | ||
| 77 | The problem with this approach is that it's not solving the whole problem, just partially (like 80%), plus it might need a lot of rewriting of the code. | ||
| 78 | The Administrator would still need to run the manual upgrade on the Core EM, but at least this would be done on the cycle, so once a year. This would improve the upgrades between minor versions (10.1 to 10.10) of the cycle. This would mean a partial upgrade, but it would bring UI changes faster. | ||
| 79 | |||
| 80 | ))) | ||
| 81 | |||
| 82 | (%class="col-xs-12 col-sm-3"%)((( | ||
| 83 | === B. OS Scripts === | ||
| 84 | |||
| 85 | When hitting the "Upgrade" button, depending on the OS, a series of scripts will be launched that they will perform all the manual needed tasks. | ||
| 86 | The problem with this approach is that it's OS dependant. Not sure if there is a solution for Windows, but this would be much simpler to realise on Debian or on OS that have RPM as a package manager (Fedora, Gentoo). | ||
| 87 | ))) | ||
| 88 | |||
| 89 | (%class="col-xs-12 col-sm-3"%)((( | ||
| 90 | === C. Cloning === | ||
| 91 | |||
| 92 | Would be nice to be able for the webapp to clone itself and do the upgrade process in a separate thread / process, while in the same container. The clone could restart itself, do all the checks, validate the success of the upgrade; and if successful, just replace the instances. Still problematic since the webapp might not be able to interact between them, also apparently we still need a Tomcat restart in order for the upgrade to run correctly. | ||
| 93 | |||
| 94 | ))) | ||
| 95 | |||
| 96 | (%class="col-xs-12 col-sm-3"%)((( | ||
| 97 | === D. XWiki Runtime === | ||
| 98 | |||
| 99 | Another component that it's only job is to handle the upgrade processes of EM... | ||
| 100 | ))) | ||
| 101 | ))) |
