Changes for page Simpler Upgrade (9.x)

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -25,7 +25,7 @@
25	25	)))
26	26
27	27	(%class="col-xs-12 col-sm-3"%)(((
28		-=== Core EM ===
	28	+=== A. Core EM ===
29	29
30	30	Have a Core EM, much simpler that is running all the time in the background. When upgrading, just upgrade the UI and the extensions.
31	31	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.
...	...	@@ -34,7 +34,7 @@
34	34	)))
35	35
36	36	(%class="col-xs-12 col-sm-3"%)(((
37		-=== OS Process ===
	37	+=== B. OS Process ===
38	38
39	39	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.
40	40	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).
...	...	@@ -41,7 +41,7 @@
41	41	)))
42	42
43	43	(%class="col-xs-12 col-sm-3"%)(((
44		-=== Cloning ===
	44	+=== C. Cloning ===
45	45
46	46	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.
47	47
...	...	@@ -48,14 +48,9 @@
48	48	)))
49	49
50	50	(%class="col-xs-12 col-sm-3"%)(((
51		-=== XWiki Runtime ===
	51	+=== D. XWiki Runtime ===
52	52
53		-Another component that it's only job is to handle the upgrade processes of EM.
	53	+Another component that it's only job is to handle the upgrade processes of EM...
54	54	)))
55	55	)))
56	56
57		-
58		-
59		-
60		-
61		-