General developer forum

Hi Kieran,

We have a similar situation with a lot of different customers whose code we manage.

There are lots of different ways to handle this situation (so I'm sure others will weigh-in with alternatives), but the way we handle it is as follows:

• For minor releases (3.5.2 => 3.5.3, etc.):
  •  we checkout the latest Moodle code (MOODLE_35_STABLE)
  • then checkout our branch
  • then create a new branch based on our current branch (all our branches are named m_3.5.2_customer, in order to keep track of our exact version)
  • then use git rebase to move our new branch on top of the latest MOODLE_35_STABLE
  • deploy this new branch
  • Note, an alternative is to simply rebase the current branch on top of the latest MOODLE_35_STABLE, but after doing a rebase you have to do a push --force, which can cause issues if other people were working on that branch
• For major releases (3.5 => 3.7):
  • Create a new branch based off the Moodle code (MOODLE_37_STABLE)
  • Download the latest versions of all plugins and add them to the code (many of the plugins will have newer versions released, so it is easier to install them all fresh, rather than trying to go through and add the updated versions)
  • Commit each plugin as a separate commit (makes it a lot easier to review the list of custom plugins)
  • Cherry-pick any core changes + custom plugins (sometimes taking an opportunity to squash the commits if there are a lot of minor bug fixes we don't need to retain the history of).

Depending on how many plugins there are to install, the major upgrade prep rarely takes more than 30-60 minutes for a customer.

I hope that helps.

Hi Kieran,

as Davo already said there are a lot of ways you can hold your plugins and moodle uptodate.

One way could be that:

1. Create a repository where you put all your plugins and store it as a branch suitable to your moodle version.
2. Create a repository with your moodle and as you already have done create a branch of your own suitable to your moodle version.
3. Merge the repository from 1) into the repository from 2)

# creating the plugin repository
git init
# Create a branch for your moodle version e.g. 3.7
git checkout -b mdl_37 
git remote add origin <your-git-url>/myplugins.git
# Put your first plugin into this repository. Do this in the correct directory, as it should be later.
git add .
git commit -m "added plugin xyz"
# Do the same for all plugins
# push the repository to the git server
git push origin mdl_37

# clone moodle in another repository
git clone -b MOODLE_37_STABLE https://github.com/moodle/moodle.git moodle
# create your own branch
git checkout -b mdl_37
# Add the first repository as remote and fetch it
git remote add myplugins <your-git-url>/myplugins.git
git fetch myplugins
# merge the plugins
git merge --allow-unrelated-histories myplugins/mdl_37
# Push it to the git server
git push origin mdl_37

We keep the core moodle repo and our changes separate and merge them together using rsync. It helps make sure we don't accidentally make changes to core moodle.

So our structure & process is something like:

~/moodle (moodle repo, or download)
~/pluginsthemesetc (same directory structure as Moodle)

$ rsync -avz ~/moodle/ /var/www/html/
$ rsync -avz ~/pluginsthemesetc/ /var/www/html/
$ php /var/www/html/upgrade.php

I use bash scripts to manage the process.

If I absolutely have to change anything in core, then I include and run patch files, but I keep these to an absolute minimum. I have one patch file for a community plugin atm, and that's it.

You might be able to "replant" your MyPD branch onto 3.7 with the git rebase --onto command.

Basically something like

# git rebase --onto MOODLE_37_STABLE MOODLE_35_STABLE MyPD

which does something like "take all commits on the MyPD branch that are not present on the MOODLE_35_STABLE branch and re-apply them on top of the MOODLE_37_STABLE branch". Read the fine manual for more details.

Like others already mentioned above, there are many creative ways you can use Git to compose code for your customized Moodle sites. In HQ we ended up with maintaining a separate branch for every single plugin or core modification. We follow a strict naming scheme for these branches which allowed us to have helper scripts for common tasks such as "take that one particular core hack we used on moodle.org and re-use it on another site" etc.

git submodule add [source_url] mod/myplugin

You can update all submodules at once using:

git submodule update

It is very easy to keep the plugins and core Moodle code separate this way, and could make upgrading simpler in the future.