Posts made by Visvanath Ratnaweera

Moodle in English -> Installing and upgrading help -> What is your strategy for a major upgrade of a site with 100 additional plug-ins? -> Re: What is your strategy for a major upgrade of a site with 100 additional plug-ins?

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Hi Marcus

Thanks for sharing your experience!

> I would always start with code from Git and if your local code has changes from that on Git then things can be problematic.
 
So you vote for starting with fresh core code, forgetting whatever the small changes I made in my (old) code tree. You must be right, those "core hacks" must be unnecessary in the new version - that is the whole idea. Since my code too is under Git I can always step through those changes, if necessary. As already said, I don't have problems with the core code - either way.
 
> One of the issues is that a plugin may work on it's own but have issues with updated versions of other plugins (rare but possible).
 
I want a working strategy, not issues!
 
Seriously, I took part and initiated my own discussions on versioning of plug-ins, which I don't want to repeat here in the hope that things have improved in the meantime.

> One of the issues is that you can never be sure if/how/what a 3rd party plug supports. To take an example..
 
So, left on their own, a plug-in may fall in to one of the following categories. I am taking 4.1 > 4.5 as an example, it is true for any major upgrade.
 
Type A. The same plug-in version I have from 4.1 is compatible with 4.5 - in the documentation and in practice.
 
Type B. The same plug-in version I have from 4.1 is compatible with 4.5 - in practice but not documented as such.
 
Type C. The plug-in version I have from 4.1 is not compatible with 4.5 but there is a version that is compatible - in practice but not documented as such.
 
Type D. The plug-in version I have from 4.1 is not compatible with 4.5 but there is a version that is compatible - in practice and documented as such.
 
Type E. The plug-in doesn't have a compatible version for 4.5 - according to the documentation and in practice.
 
Type F. The plug-in doesn't have a compatible version for 4.5 - the documentation is just silent.
 
Type G. The plug-in doesn't have a compatible version for 4.5 - according to the documentation and in practice but will break since it depends on a plug-in of type E or F.
 
Now to the question: Given a plug-in from that list of 100, how do you know to which category it falls in to?
 
P.S. I know, I should have made a table for those A-G types. I will make one, if an upcoming strategy requires that.
Average of ratings: -

Moodle in English -> Installing and upgrading help -> What is your strategy for a major upgrade of a site with 100 additional plug-ins? -> Re: What is your strategy for a major upgrade of a site with 100 additional plug-ins?

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators

The complexity of Moodle upgrades is rarely anything to do with moodle and everything to do with 3rd party plugins.

Exactly!

I'm sorry, I missed an important piece of information in my previous post. The question is solely about the plug-ins, and not a small number of them. 

Upgrading the core was simple. In fact, I did it already in a staging server. The staging server is Moodle 4.5 LTS compatible with PHP 8.2 and MariaDB 10.11. Basically I did what Moodle migration says, except that "to test the water" I took only the core 4.1 code to the staging server, and marched the code to 4.5 using Git. Then ran the Moodle upgrade script. All went well except that as expected the plug-ins page now shows 100 plug-ins missing from disk! Otherwise all works, I can navigate everywhere, Debugging raised, other than the resources and activities that came from those missing plug-ins. So no problem, no questions there.

Also note that it is simple to repeat the the core upgrade in the staging server described above. I don't mind repeating it a couple of time to find a good strategy (with you all) for the plug-ins, since other Moodle instances are waiting. ;)

-> So the question is: How would you proceed with the 100 plug-ins? <-

a) Would you take the plug-ins (the 4.1 LTS versions of them) together with the core, means the full code tree? And then what?

Or,

b) would you take only the code as I did, and install them anew? And how, with Git? Through the Moodle font-end?Again keep the number 100 written in front of you! ;)

The plug-in code is only slightly touched in a handful of plug-ins, when they broke in during production and the developers or the tracker issue showed short manual fixes - so called "code hacks".

Average of ratings: -

Moodle in English -> Installing and upgrading help -> What is your strategy for a major upgrade of a site with 100 additional plug-ins?

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators

It is upgrade time!
wink

What is your strategy for a major upgrade of a site with 100 additional plug-ins? 99 of the plug-ins are from moodle.org/plugin/ - irrespective of how they are installed; through the Moodle front-end or via Git. By "major" I mean 4.1 LTS to 4.5 LTS?

Average of ratings: -

Moodle in English -> Installing and upgrading help -> A super user friendly Moodle Installation website -> Re: A super user friendly Moodle Installation website

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators

Following the combined reply..

Haven't we been here:

Don't want to be the wet blanket. Why do we discuss various formats? Haven't the OP provided a sample of A super user friendly Moodle Installation website? Whether it means "A super, user-friendly" something or "A superuser-friendly" something or something else aside. Or that it didn't help the OP either. See Re: Moodle Server(4.1) running on going offline Ubuntu 20.04.5 LTS.

And nobody has an answer, a guess, to my puzzle earlier?

Average of ratings: -