Move a dev version of the plugin to a different branch

[dmitriim]

Would like to share a challenge that we have experienced with this plugin. That may potentially trigger to review of the way that the plugin is maintained.

We have CI tool that automatically pulls the latest changes from all "trusted" plugins to our specific upstream branch. Then if all good this would go to some of the clients. This plugin is marked as trusted so any code changes applied to master are getting pulled into our upstream.

With this change 6ff89c1 in place, we now see warning in the config setting which does make sense, but also reveals a possible way for improvements in managing branches.

Instead of having all code in master branch (which is basically becomes a dev branch after releasing a new version), do what Moodle core does - always have master/main as dev and then have stable branch(s) for all stable code. Probably don't need a branch per supported version, but name your branch as the lowest supported version + quick note in README about supported versions should be enough.

E.g. currently we would have MOODLE_311_STABLE branch as the latest stable branch which would support Moodle versions from 3.11 to 4.4. master would be non stable dev branch. When you think master has enough for a new version, then you merge it to MOODLE_311_STABLE and release a new version with a new tag.

We mostly do the same with all our public plugins. So we always have stable branches that are tested and ready to be used.

Saying all that. It's basically up to you to decide. You can close this issue without any actions if you don't think this approach suits you. Just tried to share some ways that others can use your plugin that you may not aware of.

[FMCorz]

Hi @dmitriim,

Thank you, I appreciate the feedback. We've indeed observed over the years that the master branch was incorrectly installed. To raise awareness to this issue, we added the caution warning in the admin settings. The warning does make sense, the same way Moodle displays a warning when running an unstable version, and is proving to be useful as it highlighted this issue for you.

Since the beginning, we have used tags to mark what was considered stable. This has also the benefit of differentiating between minor and major updates. We avoid any potential breaking changes in minor versions, and would not recommend automatically upgrading to the latest available version without at least some considerations.

In our documentation we recommend using the latest tag instead of a branch, is that approach not suitable to you?

[dmitriim]

Thanks for a quick reply @FMCorz

Probably whoever added this plugin to our upstream missed this documentation. I don't think we have anything configured that use tags. Probably because not many plugins actually do that. Or maybe we haven't had a similar case yet. I don't really know.

Question: if there was a breaking change in core Moodle how would you move forward with tagging approach and a single branch?

[FMCorz]

For the longest time we supported a very wide range of Moodle versions, the widest span we had was 3.4 to 4.2 if I remember correctly. We did not want plugin installers to have to worry about which branch to pick from, and we didn't want to maintain multiple branches, so we only ever maintained one version for all Moodle versions.

Our major release schedule follows Moodle's, so we usually address all potential breaking changes in time for a new Moodle release. Generally speaking, we handle the breaking change while maintaining compatibility with the older versions we support.

As you can imagine, maintaining such a wide range of Moodle versions is challenging, and with the diffence between PHP 5/7/8, it just became extremely difficult. Moreover, we could not benefit from any of the new Moodle features, which was another big drawback. So in recent years we've progressively raised the minimum required version (3.11 right now) and will progressively raise it following Moodle's LTS version.

In an edge case scenario where we need to address a breaking change in a minor version, we would proceed similarly. However, it's quite rare that Moodle introduces a breaking change that has not been handled when a deprecation notice was introduced.