18 August 2021, 13:05

Hi everyone,

The Mahara project has been around for a while and so has our Git repository along with the rules of engagement with the branches. Like everything, and especially in technology, things change, new processes are developed, new technologies used to deploy software and things are generally more automated (think DevOps). We want to support these changes as best as we can and where we have evidence that it helps a good number of people.

One of those things is what goes into our Git branches when.

The current situation

At the moment, we have 'master' (planning on renaming it to 'main') where everything goes in  as soon as a patch (bug or feature) has received a positive +2 code review and a verification. The only exception is security patches. These only get merged when we do a minor point release for the supported branches.

Each release version has a STABLE branch. As soon as a patch is merged, it is put onto that branch. When a minor point release is made, a tag is added to the branch. So that means that the tip of the branch is hardly ever on a minor point release but generally ahead. That's why if you pull the the code via Git and deploy it without pinning it to a tag, your version number will be something like '21.04.1testing' when the pinned version would be '21.04.0'. This way of doing it was chosen many years ago and memories have faded or are not available any more to question to explain the reasons. Let's just take it as a given and go from there.

Other projects, including Moodle, manage branches differently: The STABLE branch only contains code that has actually been released. Therefore, the tip of a branch of a supported version of Moodle is always the latest available minor point release. This helps automated deployment processes as they can still always pull the entire branch as they know that it's always the latest released code.

To facilitate such automations and probably also avoid a bit of confusion for developers / system administrators new to Mahara why STABLE contains unreleased code, we propose the following changes.

The proposal

1. The 'main' branch stays as it is and receives all ordinary patches as they get merged, with the exception for security updates. It is a public branch.
2. Security updates for 'main' are put onto a helper branch that is only visible to those community members in the security group. By creating a branch, we can merge code and do not keep it in draft in our code review system.
3. Each supported version of Mahara keeps its STABLE branch, but this only contains the code that goes into each minor point release.
4. Instead of being merged into STABLE, bug fixes for supported versions of Mahara, which don't see new features, go onto a public DEV branch as they are approved.
5. Security updates are merged into a SEC helper branch as they are approved. This is not publicly visible.
6. When a minor point release is made, all patches that have been identified for release from the DEV and the SEC branches are merged into STABLE for release.

A visual going with all of that

Do you have any questions or comments for this change? We are looking into making these changes for the release of Mahara 21.10 and will also discuss them at the next Mahara developer meeting on 8 September 2021. It would be wonderful to have your comments before that meeting so we can take them into consideration.

Many thanks

Kristina

15 October 2021, 12:48

Hi everyone,

Nobody has had any objections to our proposed changes for the Git branch management yet. Therefore, we are going to go ahead with them. You may have already seen that at the moment there is only a 21.10_DEV branch but not a 21.10_STABLE branch available.

I did notice though a flaw in my graphic. We are not merging security changes directly into STABLE but into DEV first so that they are available there as well. Then everything on DEV is cherry-picked into STABLE. So here's the updated version.

Thank you

Kristina