Versioning and Deprecation changes

Versioning and Deprecation changes

Matt Porritt གིས-
Number of replies: 45
Core developers གི་པར Moodle HQ གི་པར Particularly helpful Moodlers གི་པར

Hi All,

I'd like to provide everyone with an update on some changes we are making with how we describe our versions and manage our deprecation policy for Moodle LMS.

We want to make it easier for everyone who provides, manages, teaches and learns on Moodle LMS instances across the globe and those who develop functionality for our platform to understand what to expect from our versions and how we manage deprecations. As such, we have evolved how we name the versions of Moodle LMS and how we deprecate features aligned with those versions.

Before going into specifics, I want to be clear about the things that are not changing, specifically:

  • We will still release every 6 months, in April and October
  • LTS (Long-Term Support) releases will continue every four (4) versions. With the next LTS release being version 4.5
  • The release date for 4.5 (7 October 2024) and following versions have not changed

Why These Changes Matter

The shift to a more structured versioning and deprecation policy aims to provide clarity and consistency for everyone:

  • Easily identify LTS releases.
  • Understand the timeline for feature deprecations and removals.
  • Align deprecation with the LTS cycle offers a more predictable development roadmap, enabling better planning and fewer surprises.
  • Provide a more structured deprecation policy. Reducing the cognitive load on developers, allowing them to focus on innovation rather than maintenance.
  • Encourage a single branch per LTS series. Plugin developers can ensure greater compatibility and stability across Moodle versions, enhancing the overall Moodle ecosystem.

We believe these changes will reduce the cognitive load on our community, allowing developers and administrators to focus more on creating engaging and effective learning experiences.

A New Take on Versioning

Currently, the first two numbers for a version represent the major version, and the third number represents the minor version. There haven’t been set rules as to when the first number is increased, and since Moodle 2.0 there has not been any special meaning to it. The changes to this number for 3.0 and 4.0 were somewhat linked to major underlying changes in LMS, but the size of this change itself was variable. This unpredictability makes it challenging for administrators and developers to understand what an increase in version number means.

To address this we are making the change to add more meaning to version numbers, starting from version 4.5 LTS. The changes are:

  • The first part of the version will now represent a Series
  • The last release in each Series will be an LTS release
  • The next major release after an LTS will mark the beginning of a new Series

This is how this will look over the next few releases:

  • Series 4:
    • 4.1 Current LTS (released)
    • 4.2 Past release (released)
    • 4.3 Past release (released)
    • 4.4 Current release (released)
    • 4.5 Next LTS release - This is the last release in the 4.x series. (Release: 7th October, 2024)
  • Series 5:
    • 5.0 Standard release (Release: 21st April, 2025)
    • 5.1 Standard release
    • 5.2 Standard release
    • 5.3 LTS release - This is the last release in the 5.x series.
  • Series 6:
    • 6.0 Standard release
    • 6.1 Standard release
    • 6.2 Standard release 
    • 6.3 LTS release - This is the last release in the 6.x series.

Streamlined Deprecation Process

Starting from LMS version 4.5 We are also updating the deprecation policy for Moodle LMS to align more closely with the LTS cycle. The changes are:

  • Deprecations will now be aligned with the LTS release cycle, providing a clear timeline for when   deprecated features need to be updated or removed.
  • Features deprecated before an LTS release will be removed in the release following that LTS. 

This adjustment means the shortest deprecation period will be 12 months, down from the previous 24 months. Features that have been deprecated in LMS version 4.3 or 4.4 will be affected by this new approach; they will be removed in 5.0, which is the version after the 4.5 LTS.

These changes aim to foster a more consistent support cycle, benefiting both Moodle core development and plugin developers. It encourages a single plugin branch per LTS series, reducing the complexity of supporting multiple Moodle versions.

More information on both of these issues can be found in their respective trackers, IDEA-168 for versioning and MDL-80274 for deprecations. We will be also updating our developer documentation to aid developers with the changes and how they should manage their plugins.

Kind Regards,
Matt Porritt
Head of Platform Solutions

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (14)
In reply to Matt Porritt

Re: Versioning and Deprecation changes

David M གིས-

I only stumbled across this thread while searching for something else, so this was the first I was aware of this proposal.

I'm not a Moodle developer, but I am a site administrator. I'm afraid to say (for what it's worth, if anything), that I'm not very keen on this numbering scheme. Version numbers are indeed generally somewhat arbitrary, but I agree that is very useful to know which releases are LTS releases (and often, just including LTS in the release name serves that purpose very well). 

I would be idly curious as to how many sites (as opposed to developers' test sites) do actually use the short-term releases (I'd definitely call these short-term, rather than standard; not quite as short a lifespan as Ubuntu short-term releases, but comparable in a way), rather than the LTS versions. I suspect that many sites, including ourselves, just don't have the resources or energy to be doing a big update every single year, with all that can potentially go wrong (and including dealing with feature changes and any instructor/student re-training), and so just go for patch updates to the LTS yearly (or more frequently where possible), and then do the big LTS jump only every couple of years?

On that note, having LTS versions being fixed to be x.3 seems a bit 'ugly' from an aesthetic perspective, rather than just slotting in when due, as at present.

It is obviously up to the Moodle development team to decide when the project needs a major version bump from 4.x to 5.x, etc (and for many projects that can either be a bit arbitrary, or based on something that "merits it" like a major rewrite, major functionality change, or non-backwards-compatible change (which often implies at least one of the other two anyway)). 

But, regarding this new plan, if it was up to me, I would make the x.0 version the LTS release (partly as that seems 'tidier' and more elegant, and, I dare say, easier to remember), with the subsequent x.y releases being the short term releases before then building up to the next x+1.0 LTS release (so the next short term releases from now would still be 4.6, 4.7, etc, until then reaching 5.0 LTS). Having the LTS release as a 'minor version number' at the end of a major-number cycle will seem confusing to many people, I suspect? (As we generally don't use the short-term/intermediate releases, I tend to regard them as pre-next-LTS versions in practice, and see the next LTS as the next significant number. (Having said that, I am about to install a 4.4 test server so that we can start to check our code for PHP version compatibility ahead of 4.5 LTS coming.))

Just some small thoughts, but, nevertheless, big thanks to the Moodle developers for all their hard work!

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to David M

Re: Versioning and Deprecation changes

Dan Marsden གིས-
Core developers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར Plugins guardians གི་པར Testers གི་པར Translators གི་པར
Hi David - I know the HQ team spent a lot of time looking into the various version naming options - what they have settled on here lining it up with the deprecation process makes quite a lot of sense to me and should simplify a number of things.

One big advantage that might not be clear is that if a 3rd party plugin works in 5.0 it should also work fine in 5.3, but then may break in 6.0 - we also like the last release in the series being the LTS version too.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (6)
In reply to Dan Marsden

Re: Versioning and Deprecation changes

Séverin TERRIER གིས-
Documentation writers གི་པར Particularly helpful Moodlers གི་པར Testers གི་པར Translators གི་པར
Hi,

At first reading, i understand that having the LTS version being x.0 is simpler to retain (for an administrator, like me), but that would mean end of support would be (nearly) at the same time of the last version of the serie, meaning that no version of this branch is supported.

The proposed naming means you know the LTS version will be x.3, and it allows to use a rock solid version, build on things polished since x.0 version, and that will still be maintained for 2 years དགའ་འཛུམ་

And then, you jump to a new serie, with new important (technical) changes.

I think it make sense.

Séverin
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (4)
In reply to David M

Re: Versioning and Deprecation changes

Neill Magill གིས-
Core developers གི་པར Peer reviewers གི་པར Plugin developers གི་པར
We tend to upgrade every year, so use plenty of standard versions.

Before Moodle 4.0 got delayed by 6 months the version we upgraded to would almost never have been an LTS release.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Matt Porritt

Re: Versioning and Deprecation changes

Bret Miller གིས-
Particularly helpful Moodlers གི་པར
I really like this approach. After 4.5, it will be easy to tell if a version is LTS or not. I don't really have a preference if it's x.3 or x.0 being LTS. x.3 makes slightly more sense to increment the major version to imply possible code-breaking changes. Of course any version upgrade could break something. For those who want infrequent updates, knowing that x.3 will be support for security patches longer than other versions is a good thing.

We opt for a middle of the road upgrade plan. We upgrade twice a year to the -1 version of Moodle. We used to do the latest version but got bit by functionality-breaking bugs more than once. Since that inhibits students' and teachers' ability to function in their courses, we decided to step back a version and let it settle before upgrading to it.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Matt Porritt

Any plans on changing LTS periods?

Johannes Burk གིས-
Core developers གི་པར Plugin developers གི་པར
Are there any plans on changing the period for general bug fixes for LTS versions too? I first wanted to post this as a reply to another thread but now decided to post it here (or should I've opened a separate thread for it?):
 
I'm currently a bit unhappy with the LTS general support period. I understand that LTS currently refers only to security updates... The period for general bug fixes - even critical ones - is the same as for all other major versions (~ one year). This leaves you with a window of ~10 months without general bug fixes when you want to stay on LTS versions. Here is a tracker search with bugs reported affecting versions 4.1* but only got fixed on versions >=4.2*. 96 including minor and still 14 bugs with at least critical priority.

I would like to wish for a "long term general support version" to combine reduced major update frequency and still getting general bug fixes.

Example from Ubuntu: the end of standard support for an LTS release is around a year after the next LTS version was released (end of security support is even later). This gives enough time to upgrade from one LTS to the next without missing bug fixes.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Johannes Burk

Re: Any plans on changing LTS periods?

Matt Porritt གིས-
Core developers གི་པར Moodle HQ གི་པར Particularly helpful Moodlers གི་པར
Hi Johannes,
Thanks for your feedback. There are no plans to change the current general and security support time periods for either general or LTS versions of Moodle LMS.
This decision is based on a balance between providing extended security support, which is crucial for stability and compliance, and managing the resource allocation that allows us to continue advancing the platform with new features and enhancements.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (2)
In reply to Matt Porritt

Re: Versioning and Deprecation changes

Thorsten Bartel གིས-
Core developers གི་པར
As an administrator, I'm looking forward to these changes mainly because:
  • having the last release in a series be the LTS release will make it easier to switch to the new series on our terms
  • shorter periods between series will likely result in a much smoother transition from series to series with less major components overhauled (less possibly breaking changes)
  • having a period of 24 months from one series to the next ensures the same distance between LTS releases - whereas in the past, the distance between 3.9 LTS and 4.1 LTS was difficult to anticipate due to ...
  • ... delays between releases / a new major major release messing up the schedule, which sounds less likely to happen with the new plan.

Are there any plans to tie series versioning with PHP versioning more rigorously?

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Thorsten Bartel

Re: Versioning and Deprecation changes

Brett Dalton གིས-
Moodle HQ གི་པར Particularly helpful Moodlers གི་པར
Thorsten

Moodle release cycles is pretty much set and regular now so baring a disaster delays will be a thing of the past. Given PHP releases Nov/Dec fairly regularly and Moodle is April/October the supported version should be more predictable moving forward, but we will still be assessing release to release based on risk and level of effort.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Matt Porritt

Re: Versioning and Deprecation changes

James Calder གིས-
Plugin developers གི་པར

I've only just come across this, and mostly I love it, but I'm not sure about having the LTS right at the end of the series, especially if the aim will be to have major new features introduced at the start of a series (like the Moodle 4.0 interface).  I think there's a balance to be struck.

If major new features are introduced at the start of a series, then a downside of having the LTS at the start is that LTS users will get bleeding-edge major features at the same time as STS users, but a downside of having the LTS at the end is that LTS users will have to wait for longer for new major features.

Regardless, a downside of having the LTS at the start is that LTS users will have features deprecated at the same time as STS users, but a downside of having the LTS at the end is that developers will have to support old tooling and old code for longer.

I think a year of STS use is probably long enough to consider things ready for LTS users.  General support only usually lasts for a year, so if an LTS for a series isn't released within a year of the start of the series, the old series will be in a sense kind of obsolete before LTS users get the chance to upgrade to the new one.  So I think it may be better to have the x.2 version as the LTS.

As a plugin developer, this affects me because, while I will hopefully be able to limit my number of branches to one per series, which I think would be great, I will still have to support an old branch for quite a long time.

I missed the discussion for this, so I guess the decision is already made for upcoming releases.  But maybe this could be considered at some stage in the future?

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to James Calder

Re: Versioning and Deprecation changes

James Calder གིས-
Plugin developers གི་པར
Actually, come to think of it, if users that have been upgrading to STS versions find the next series difficult to upgrade to, they'll be left on an LTS with more time to resolve issues, so perhaps it's not such a bad idea.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (2)
In reply to James Calder

Re: Versioning and Deprecation changes

Dan Marsden གིས-
Core developers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར Plugins guardians གི་པར Testers གི་པར Translators གི་པར
I think you may be confusing deprecation with features.

In the past, the .0 releases have been somewhat linked to major underlying changes, but now these will just follow a predictable pattern and major new features will just be introduced in every major version.

Deprecation mainly relates to custom code - either plugins or custom scripts an organisation has added to their site. The new deprecation policy means that something that works in Moodle 5.0 may break in 6.0.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to James Calder

Re: Versioning and Deprecation changes

Visvanath Ratnaweera གིས-
Particularly helpful Moodlers གི་པར Translators གི་པར
As a system administrator the current suggestion, "LTS is the last of the series", is natural to me. In layman terms: LTS speaks to those who prefer stability over bleeding-edge. As we all know, one can't have both. In this case, stability means "old", mature. So once Moodle 5 series is out, those who belong to the former group will remain in Moodle 4 series and happy to be in a 4.5 LTS. They are there by choice and not disturbed to be in an "old" series. In fact old series number is good as an immediate identification; not that people from the bleeding-edge group start telling them "latest and the shyniest" is the best.

On, "I will hopefully be able to limit my number of branches to one per series, which I think would be great, I will still have to support an old branch for quite a long time." I'm not a developer but use additional plug-ins heavily. Yes, a branch per series is the suggestion here. But the argument is that the old branch will offer feature updates for 12 months only like any non-LTS version; only security patches need to be offered 18 months longer (24 as opposed to 6 months). 

A plug-in is generally not something big like the Moodle core. So after 24 months and three major Moodle versions, the chances of discovering more security bugs in the coming 18 months should be small. More importantly, maintaing the old branch that longer is ultimately a question whether the developers community accept the legitimacy of the former group.

In fact, that there is no unified version scheme for plug-ins is a huge problem for the system administrator. Not to take this discussion off-track, please comment in its own thread A common branch names scheme for additional plug-ins?
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Visvanath Ratnaweera

Re: Versioning and Deprecation changes

James Calder གིས-
Plugin developers གི་པར

Re supporting old branches, yes I agree, the chances of security bugs being found late in the branch life-cycle are probably low.  But just in case, I want to be prepared to respond in a timely manner, for a branch that's used by a Moodle version that's still receiving security support--I think that's probably the right thing to do.  But I also want to keep the code prechecks tick--it's there as an indication of standards that plugins should adhere to, so I think that's also probably the right thing to do too.  But the code standards are evolving, so to be able to respond in a timely manner while adhering to the code standards, I need to keep supported branches up to date with evolving code standards.  I only need to support one branch at the moment, but under the new system that will be two or three at any given time, I think.

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to James Calder

Re: Versioning and Deprecation changes

Visvanath Ratnaweera གིས-
Particularly helpful Moodlers གི་པར Translators གི་པར
Hi James, hi all

One thing, before we dive deeper: The introduction of the Moodle version "series" does not increase the work of the plug-in developers. It is the LTS that give more work. But LTS in the present format, every fourth major version will be an LTS, is nothing new - it is there since Moodle 3.1: 3.1, 3.5, 3.9, 4.1 all were LTS. LTSes get 12 months general support plus 24 months security support as opposed to non-LTS, which also get 12 months general support plus only 6 months security support. So those additional 18 months security support is the only difference. It is all there in https://moodledev.io/general/releases.

That is for the core. The changes introduced in this thread do not create additional work for the core developers, even today they create a branch per Moodle (major) version and maintain them according to the general release plan https://moodledev.io/general/releases.

But we have diverted to the work of the plug-in developers. We have discussed that at length in the old thread I already mentioned, A common branch names scheme for additional plug-ins? I'm presenting here a proposal which came up in that thread: https://moodle.org/mod/forum/discuss.php?d=454264#p1841914.

Let's look at it in real dates:
- Today (May 2024). Let's assume you maintain only one "branch", the Head, in you Git repo. It supports Moodle 4.1 LTS and 4.2 security only and to 4.3 and 4.4 general according to the release plan.

- October 2024, Moodle 4.5 LTS will be released. No change. Still Head, corrections for 4.5 LTS done.

- April 2025, Moodle 5.0 will be released. Now you have to make a branch for the Moodle 4 series. The head will be for Moodle 5.x, initially corrected for version 5.0.

- October 2025, Moodle 5.1 will be released. No changes in the Git branching (still Head and 4 series)

- April 2026, Moodle 5.2 will be released. No changes in the Git branching (still Head and 4 series)

- October 2026, Moodle 5.3 LTS will be released. No changes in the Git branching (still Head and 4 series)

- April 2027, Moodle 6.0 will be released. Repetition of what happened in April 2025,  Now you have to make a branch for the Moodle 5 series. The head will be for Moodle 6.x, initially 6.0

Important, you can stop maintaining the 4 series branch.

And it repeats.

In effect, at any given time, you will have only two branches to maintain: the Head and the previous series. I know, it is more than maintaining one branch, a Head. But you don't abandon the "stability first" group.
མིག་ཁྱབ་

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Visvanath Ratnaweera

Re: Versioning and Deprecation changes

Dan Marsden གིས-
Core developers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར Plugins guardians གི་པར Testers གི་པར Translators གི་པར

Hi Visvanath, 

One of the challenges your proposal above doesn't solve is that people often use submodules to add plugins to their codebase, and sometimes will automate processes to pull in new changes.

In particular this statement you made:
"Moodle 5.0 will be released. Now you have to make a branch for the Moodle 4 series. The head will be for Moodle 5.x, initially corrected for version 5.0."

means that someone using a Moodle 4.x branch pointing at "main" with automation - will pull in a change that suddenly breaks their site and they will have to do work on their end to fix the branches used in their submodule checkout.

What we do here at Catalyst with most of our plugins is that we don't use a branch named "main" at all, the latest branch name will be named after the earliest Moodle branch it supports.

example:

Saml2 has a current "latest" branch name called "MOODLE_39_STABLE" - this supports all versions since MOODLE_39_STABLE

If something in Moodle 5.0 means we have to create a new branch - we call that new branch MOODLE_500_STABLE and then when something after that means we need a new branch, we create MOODLE_600_STABLE etc.

This means if a Moodle 4.1 site using submodules linking to MOODLE_39_STABLE still functions correctly and you don't need to change the branch it's currently using.

you will see this in other plugins of ours like:
https://github.com/catalyst/moodle-tool_mfa?tab=readme-ov-file#moodle-supported-branches
https://github.com/danmarsden/moodle-local_recompletion

you might see some of our older plugins with different naming but the new stuff should all follow that process.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (3)
In reply to Dan Marsden

Re: Versioning and Deprecation changes

James Calder གིས-
Plugin developers གི་པར
That sounds sensible to me. What would be the process for making this an official recommendation? And do you think it would be best to rename existing branches, or just adopt this going forward?
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Dan Marsden

Re: Versioning and Deprecation changes

Visvanath Ratnaweera གིས-
Particularly helpful Moodlers གི་པར Translators གི་པར
Hi Dan

That is exactly the problem. Theoretically each plug-in can have its own versioning concept, which is a huge problem for the system administrator. (@others, for details see the other discussion A common branch names scheme for additional plug-ins?) As a result each system administrator has his own sub-optical solution (Git submodules is one of them) or no solution at all.

So my question is, can't HQ impose a versioning concept for additional plug-ins if they were to be included in the official plug-in database? Or, am I naive?

About the detail problems you've raised in the latter half of your post: Once that common version scheme is in place we can look in to them. "My proposal", which in fact was posted in the other thread by Andrew, is just a sketch. We need a core developer (you?) or the OP Matt P. to formulate it properly. No point in discussing this rough sketch in detail. I've posted literally a sketch in the reply to James Calder here.
མིག་ཁྱབ་
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Visvanath Ratnaweera

Re: Versioning and Deprecation changes

Davo Smith གིས-
Core developers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར

The simple answer is, that Moodle does enforce a versioning concept on plugins - it's built-in to the Moodle plugins directory.

If you pull the data from there, you get a list of which released version of each plugin is suitable for any given version of Moodle, along with a link to download it (there's a 7MB JSON file you can pull down with everything in it - that's what our company's internal tools use for managing 3rd-party plugins).

Some plugins may support and encourage people to download them from github, in which case feel free to do so.

I can state, for example, that none of my own plugins offer stable versions in github - you can download from there if you want, but the stable, supported versions are in the plugins directory. There is no need for me, as a plugin developer, to conform to any particular branching scheme, because github is just the place where the current development code is kept for the plugin.

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (4)
In reply to Davo Smith

Re: Versioning and Deprecation changes

Thorsten Bartel གིས-
Core developers གི་པར
Sorry for going off on a tangent here, but I have a quick follow up because the "sub-optimal solution" of git submodules Visvanath mentioned is something we utilize as well.
If there is a change log linked in the plugins directory and maybe even a VCS tag specified, we regularly interpret this to imply: "This commit in our git repository is identical to this version of the plugin in the directory."

Is this not the case? Or what are examples where the release in the plugin directory differs in a meaningful way from the linked / referenced commit on GitHub?
Maybe you're just covering your base in case not so git-versed people get lost and consequently create support noise where it could be prevented by redirecting to a uniform source?

Just as an example: https://github.com/davosmith/moodle-checklist/commits/4.1.0.2
Everything in the plugins directory and on GitHub implies (to me) that the commit I linked is identical to the plugin version uploaded to and published in the plugins directory.

Anyways, thanks for your insights so far!
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Thorsten Bartel

Re: Versioning and Deprecation changes

Neill Magill གིས-
Core developers གི་པར Peer reviewers གི་པར Plugin developers གི་པར
If you were to look at most of our plugins you would not find a commit or tag relating to a specific version number.

I imagine I could look in many repositories for plugins in the plugins directory and find something similar, there is nothing in the plugins directory that requires it.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Thorsten Bartel

Re: Versioning and Deprecation changes

Davo Smith གིས-
Core developers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར
Often new code is merged into the branch in github and then I wait to see results of the automated tests to make sure I've not accidentally broken something in one of the other branches (or with a certain PHP version).

I can also sometimes fix a bug in github and ask the reporter to confirm that the fix has solved the problem (and not immediately introduced some other issues).

In both of those cases, I don't send the new code to the Moodle plugins directory until I'm (more!) confident that I've not caused a problem with the updated code.

Much of the time the code in github and the plugins directory is identical (especially as I don't make that many changes outside of Moodle major releases), but there are windows of time when github contains code that is more likely to have issues.

During my work time, we carefully manage our branches and have a QA/UAT process whilst moving between branches (plus we don't have to worry about supporting multiple Moodle versions at once, as each customer we are writing the code for is only on a single Moodle version). In my spare time, when I maintain my own plugins, I'm not really willing to put in the extra time required for that level of branch management.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Thorsten Bartel

Re: Git work-flow(s) for Moodle additional plug-ins

Visvanath Ratnaweera གིས-
Particularly helpful Moodlers གི་པར Translators གི་པར
Hi Thorsten

Unfortunately the topic we discuss now is not the same as the original topic, Versioning and Deprecation changes, which was about the Moodle core. I would call this sub-thread, starting here, "Git work-flow(s) for Moodle additional plug-ins". Incidentally I have started a (full) discussion on the same question some time ago under A common branch names scheme for additional plug-ins? which ultimately looped back this "dual" discussion.

@Thorsten and all, The result of the above mix up it that people repeat themselves. To bring that to an end I try to summarize the outcome:

- The Moodle HQ, as the maintainer of the plug-in database doesn't impose any Git workflow(s) for the plugins there. They expect the plug-in developers to submit zip files instead. Those are the ones which are shown under each plugin-database/plugin-name/versions and offered to downloaded or picked up by the Moodle front-end plug-in installer yoursite/admin/tool/installaddon/.

- As a result the developers of each plug-in is free to follow whatever Git workflow convenient for them. Means, there are a multitude of workflows.

Curiously, almost all plug-ins have a GitHub link published on its plug-in database, although there is no common understanding what that GitHub repo really is.

So the net result is, the system administrators (OS level, mainly Unix shell) have to either run a different set of Git commands for each plug-in or give up Git entirely and fall back to the zip archives - which is a step backward compared to the forward step Moodle made over a decade ago to move from Zip files to Git.

- The recent discussions resulted in the HQ to Encourage plugin developers to have one branch per Moodle series.

End of it (as of June 2024)! Please correct me, if I am wrong.

P.S. Dear moderator, I still think splitting this discussion at the start of this sub-thread will dampen at least part of the confusion.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Visvanath Ratnaweera

Re: Git work-flow(s) for Moodle additional plug-ins

Iñaki Arenaza གིས-
Core developers གི་པར Documentation writers གི་པར Peer reviewers གི་པར Plugin developers གི་པར

Hi Visvanath,

while I understand your point of view, I think it's important to keep facts as straight as possible དགའ་འཛུམ་ Which in this case, revolves around the following statement:

which is a step backward compared to the forward step Moodle made over a decade ago to move from Zip files to Git.

Moodle didn't move from Zip files to Git. Moodle moved from "only"[1] offering Zip files to offering Zip files and Git "on equal footing". But, curiously enough, if you go to the downloads page, you are offered Zip files (and Gzipped Tar files). And only if you know your way, or digg a bit around, you are offered the Git repository.

I know for many sites and people Git is more convenient than Zip files. I've used that myself. But stating that Git is the Moodle HQ preferred way of delivering Moodle is, IMHO, not the (whole) truth.

On the other hand, for the Moodle Plugins database, source code repositories were never -as far as I know- the official (or preferred) way of distributing the plugins, from Moodle HQ's point of view. The mere fact that the source code repository attribute is optional in the Moodle plugins database, should probably convey a strong message in that direction དགའ་འཛུམ་

[1] This is not 100% true either. CVS, and later git, was always an alternative options to Zip files.

Saludos.

Iñaki

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Iñaki Arenaza

Re: Git work-flow(s) for Moodle additional plug-ins

Visvanath Ratnaweera གིས-
Particularly helpful Moodlers གི་པར Translators གི་པར
Hi Iñaki

That was an Aha! reply. We are talking of the same historical events experiences differently by the two of us. ;)

If I follow your side of the story, the pieces fall in to place:
- The primary source of Moodle core has been a zip file from day 0 and will be a zip till infinity. The early CVS and current Git repos are just bonuses without an official status.

- The primary source of Moodle plug-ins in the plugin database are zip files! Their developers may offer a versioning repo, e.g. on GitHub, but there is absolutely no general rules and conditions imposed on them.

If that is true, I have been in the dark for almost two decades. You know, better light now than never.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Visvanath Ratnaweera

Re: Git work-flow(s) for Moodle additional plug-ins

Iñaki Arenaza གིས-
Core developers གི་པར Documentation writers གི་པར Peer reviewers གི་པར Plugin developers གི་པར

If I follow your side of the story, the pieces fall in to place:

  • The primary source of Moodle core has been a zip file from day 0 and will be a zip till infinity. The early CVS and current Git repos are just bonuses without an official status.

CVS could be construed as a bonus (in the sense that I suspect very few people used it to deploy production systems, because of its many shortcomings). But Git, as I said, is now on an equal footing as the Zip files. (IMHO, not talking on any official capacity, much less on Moodle HQ's name, etc.) Not "bonuses without official status", but "actual peers, with equal official status".

I posit that this is not the case for non-core plugins. That is, those plugins that are available through the Moodle Plugins database. Because, as I said, the source code repository is not even a mandatory property in the Plugin database. You could very well publish a plugin in there, without any source code repository.

My TL;DR: Moodle core moved from Zip files to Zip files AND Git. Non-core plugins (as managed by the Plugins database, which I think is the relevant source when talking about plugin development policies) never did that transition.

Saludos.

Iñaki.

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Iñaki Arenaza

Re: Git work-flow(s) for Moodle additional plug-ins

Dan Marsden གིས-
Core developers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར Plugins guardians གི་པར Testers གི་པར Translators གི་པར
Valid source control repository links (doesn't have to be git-based) and public issues tracker are requirements for plugins hosted in the plugins db - we will occasionally remove plugins from the db if the original developer removes their source control repo links as these are typically considered "abandoned".

There is also no official requirement for a "primary location" for a plugins latest stable files - developers are often time-limited - the plugin may be written for some project used by their organisation and they may push updates/fixes to git, but neglect to update the plugins database with the new release. This is just the nature of open-source - you can't "force" people to work in a certain way, just have policies that allow for good practice/structures to be followed.

At Catalyst - we use git for all our plugin deployment processes - we don't rely on the plugins db for our own plugins - so we will often push fixes to our public github repositories but not always remember to update the plugins db.
 
We do see the value in publishing to the plugins database, so to try and improve this we developed some improvements to the github actions tooling and now use reusable workflows - when we bump the version in the version.php file and the github action tests pass, it will auto-deploy the new version to the plugins db. But - apis are always changing, and tests do not always pass - so sometimes you will need to wait for one of our clients to upgrade to that release, (who pay for our time to fix the tests) or for someone in the community to push a fix through or alternatively, the code is there in github for you to download if you don't want to wait.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Visvanath Ratnaweera

Re: Versioning and Deprecation changes

James Calder གིས-
Plugin developers གི་པར
If LTSes get 12 months general support plus 24 months security support, that's 3 years. If Moodle 4.5 LTS is released October 2024, that means support ends October 2027. If Moodle 6.0 is released April 2027, that's April-October 2027 when series 4, 5, and 6 are receiving security support.
But in any case, I've come around to the idea.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to James Calder

Re: Versioning and Deprecation changes

Visvanath Ratnaweera གིས-
Particularly helpful Moodlers གི་པར Translators གི་པར
Hi James

You wrote:
> that's April-October 2027 when series 4, 5, and 6 are receiving security support.

You found a mistake in my post:
>> - April 2027, Moodle 6.0 will be released. Repetition of what happened in April 2025, Now you have to make a branch for the Moodle 5 series. The head will be for Moodle 6.x, initially 6.0
>>
>> Important, you can stop maintaining the 4 series branch.

You can stop the 4 series branch only in October 2027. It is essential, it gives the "stability first" people 6 months to upgrade from old LTS to new LTS. So during those three months there are three branches (counting the head) to maintain. Hopefully not many security holes in the old LTS will come up during this period.

N.B. Your current scheme, Head only, is not touched until April 2025.

Here's an amateurish sketch. The editable version, in LibreOffice Draw format, is attached:

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Visvanath Ratnaweera

Re: Versioning and Deprecation changes

Neill Magill གིས-
Core developers གི་པར Peer reviewers གི་པར Plugin developers གི་པར

I think forcing a branching structure on plugins would not work not least because there has never been one, also what is required of a plugin may or may not change between versions.

For example a repository plugin is unlikely to have needed many changes over the years to stay working (it may just have needed to add a privacy provider, it has probably needed more changes to keep any automatic tests working than for functionality reasons), however an activity plugin probably has needed fairly regular changes if it wants to keep up to date with the latest features and looks of activities.

There are also likely to be considerations around the way development happens within the organisations that make the plugins that may determine if an approach to branching in their repository works for them.

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Visvanath Ratnaweera

Re: Versioning and Deprecation changes

James Calder གིས-
Plugin developers གི་པར
I think a recommended plugin branch naming scheme would have to be based on major version numbers, not just series. Although I think one branch per series will probably work well for my plugin, I'm not sure this will always be possible for everyone. I think it's possible that, despite best intentions, some change within a series might break a plugin, and more than one branch within a series might be needed. And going the other way, if a new series doesn't break a plugin, then there may be no need for a new branch.
Dan has said that having the current stable named 'master' or 'main' rather than based on the Moodle version number doesn't work well for submodules, and since people are using this, I think it's best to support it.
And obviously the branch would have to be named after the first supported major version only, since the last supported won't necessarily be known in advance.
So I think the question just remains, how should the Moodle version number be written as a branch name? And Moodle already has a branch naming scheme for this, so we may as well use that. Plus, some people are already using it.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to James Calder

Re: Versioning and Deprecation changes

Dan Marsden གིས-
Core developers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར Plugins guardians གི་པར Testers གི་པར Translators གི་པར
While I understand the difficulties of the inconsistent branch naming in plugins and it would make my life as a developer a lot easier if we all conformed to a specific standard, I would not personally support enforcing a branch naming standard for plugin developers submitting plugins to the database.

We could add a recommendation on branch naming which might improve adoption across multiple plugins, although before we do this formally for plugins, I'd prefer to see what happens in MDLSITE-7675 because it would be preferable for any recommendation to follow whatever the Moodle core branch naming becomes.

If anyone is interested in the sorts of things that currently "block" approval in the plugins db, the list of those is here:
https://moodledev.io/general/community/plugincontribution/checklist#approval-blockers

..and of course - we're always keen for people to help out with the reviews, so reach out to David Mudrak or myself if you are interested in helping with plugin reviews!
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (2)
In reply to Dan Marsden

Re: Versioning and Deprecation changes

Visvanath Ratnaweera གིས-
Particularly helpful Moodlers གི་པར Translators གི་པར
Hi all

Davo Smith - Wednesday, 22 May 2024, 18:37 UTC wrote:
> The simple answer is, that Moodle does enforce a versioning concept on plugins - it's built-in to the Moodle plugins directory.

You mean the zip files as in plugins/pluginname/versions, I assume. That a huge surprise to me. From the time Git was introduced to the core code, it was the preferred download format. We in the Installing and Upgrading forum are repeatedly advising people to follow Git_for_Administrators#Obtaining_the_code_from_Git. Somehow I deduced from that Git is also the preferred format for the plug-ins. Since each plug-in may have its own versioning concept, every major upgrade had become a tedious process. So, you confirm that this is expected? I tried the Git submodules route without success, for the same reason. Or, is there a documentation somewhere how to maintain the plug-ins with Git submodules?

> Some plugins may support and encourage people to download them from github, in which case feel free to do so.

Every plug-in I use points to a Git repo, 95% on GitHub, in its plugins/ page. How does one know who encourage to use them?

> because github is just the place where the current development code is kept for the plugin.

When you mention it, sounds convincing. But how does the core do the same and still the users are also able to get the code from there?

Dan Marsden - Thursday, 23 May 2024, 10:23 UTC wrote:
> While I understand the difficulties of the inconsistent branch naming in plugins and it would make my life as a developer a lot easier if we all conformed to a specific standard, I would not personally support enforcing a branch naming standard for plugin developers submitting plugins to the database.
>
> We could add a recommendation on branch naming which might improve adoption across multiple plugins, although before we do this formally for plugins, I'd prefer to see what happens in MDLSITE-7675 because it would be preferable for any recommendation to follow whatever the Moodle core branch naming becomes.

Of course, the interests of all parties need to be considered. And specially both of you as core developers and plug-in developers have the overview.

@all, Please express your opinion too - either here or in the tracker.

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Visvanath Ratnaweera

Re: Versioning and Deprecation changes

Neill Magill གིས-
Core developers གི་པར Peer reviewers གི་པར Plugin developers གི་པར
For our open source plugins I would not recommend anyone taking directly from the repository directly to their live environment, since we may have code that has not been fully tested by us in it, while when we deploy to the plugins directory it will have been tested.

i.e. if you were to take directly from our repositories you would need to make sure you tested it before deploying it to your live environment.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Neill Magill

Re: Versioning and Deprecation changes

Dan Marsden གིས-
Core developers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར Plugins guardians གི་པར Testers གི་པར Translators གི་པར
yeah - there's a lot of variation on that for plugin developers too.... Here at Catalyst - the latest stable releases for our plugins will always be in github - we don't actively push out versions to the plugins db, but are slowly rolling out auto-deployment to plugins db based on github workflows. We don't rely on versions in the plugins db ourselves at all - we automate updates using git/submodules/CI processes.
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Dan Marsden

Re: Versioning and Deprecation changes

Visvanath Ratnaweera གིས-
Particularly helpful Moodlers གི་པར Translators གི་པར
Hi all

The new naming convention in the original post is now accepted at yesterday's developer meeting.




And also together with the new deprecation policy to "Encourage plugin developers to have one branch per Moodle series".




དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (2)
In reply to Visvanath Ratnaweera

Re: Versioning and Deprecation changes

Visvanath Ratnaweera གིས-
Particularly helpful Moodlers གི་པར Translators གི་པར
Very late to ask the simplest question: Will the Git tags remain three digit MOODLE_501_STABLE for example, or will they be back to two digit, MOODLE_51_STABLE as in the pre-4.x times? The three digit notation proved to be cumbersome. Now in the new versioning scheme there will never be a Moodle X.10 or higher, there's no need for three digits!
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (1)
In reply to Visvanath Ratnaweera

Re: Versioning and Deprecation changes

Andrew Lyons གིས-
Core developers གི་པར Moodle HQ གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར Testers གི་པར
We will never have a new git tag or branch name which is lower than an existing one.
Since 51 is smaller than 501, the answer is no.

When we get to Moodle series 10 (10.X.Y), we will move to a four-digit number.

It is highly unlikely with the new approach that we will ever get to two-digit major version (X.10.Y).
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Andrew Lyons

Re: Versioning and Deprecation changes

Visvanath Ratnaweera གིས-
Particularly helpful Moodlers གི་པར Translators གི་པར
Thanks for the quick explanation. If I may rephrase, the transition from MOODLE_30_STABLE, MOODLE_31_STABLE,.. MOODLE_311_STABLE to MOODLE_400_STABLE, MOODLE_401_STABLE,.. MOODLE_405_STABLE is irreversible because that will upset Git since 51 is (numerically) smaller than 501. 

Well, the "tags" I am talking about, MOODLE_405_STABLE, etc. are textual - not numerical, I don't see where numerical comparisons are being made on them. If you have considered this change and have strong reasons against, I respect your decision. I don't (have to) meddle with Moodle and Git. I want to put to the record that the MOODLE_405_STABLE kind of tags since Moodle 4.x proved to be cumbersome and confused many system administrators. (There are plenty of examples in the forums, I don't want to return to.)
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Visvanath Ratnaweera

Re: Versioning and Deprecation changes

Andrew Lyons གིས-
Core developers གི་པར Moodle HQ གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར Testers གི་པར
Hi Visvanath,

Whilst they may be lexical, they must match the numeric version, and they are also converted into numeric versions for various tooling. Most of this tooling relates to our internal release processes.

If you provide some examples of the issues that they cause, then we can look to help, but we will not be moving to a 2-digit version system at any point in the future.

Andrew
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Andrew Lyons

Re: Versioning and Deprecation changes

Visvanath Ratnaweera གིས-
Particularly helpful Moodlers གི་པར Translators གི་པར
Andrew, I haven't automated a great deal. The Git work-flow, the shell commands and the occasional shell scripts have adjusted to the three-digit version during the long 4.x era. So a two-digit version is not direly needed for my purposes. If you say, there is no way going back to two-digit, no point in looking at the confusions users had in the past, and some still have, in detail. Basically the problem was: What is MOODLE_401_STABLE? Is it 4.0.1? Or 4.10? Or something entirely different?

I have no problem in remembering the answer. (MOODLE_401_STABLE stands for the whole set of 4.1 releases, the whole branch, i.e. 4.1, 4.1.1, 4.1.2,.. 4.1.15,.. and the weeklies in between!) I thought MOODLE_41_STABLE is more intuitive and would help the uninitiated. If there are very strong reasons for MOODLE_401_STABLE notation and as you say, the Moodle developers have built their tools based on that assumption, "intuition" is not a sufficient reason for a change, even if possible. མིག་ཁྱབ་
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Visvanath Ratnaweera

Re: Versioning and Deprecation changes

Davo Smith གིས-
Core developers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར
How does core maintain stable code in a public git repository?
Moodle has 2 git repositories - an 'integration' git repository, where new development code is merged and the general git repository where this code is transferred, after it has been through the testing process. As an individual plugin developer, mostly maintaining my own plugins in my spare time, I don't have the resources to undertake such an approach, so I keep the development code in github and only deploy it to the Moodle plugins directory when I am (reasonably) confident it is fully tested and working.
 
(Almost) every plugin points to a git repository, how do you know if you should use them directly?
The git repositories are there for anyone who wants to directly access the current work-in-progress development code, or to submit bug reports or patches. If someone writes in the plugin documentation, for a particular plugin, that they make the latest stable code available on a particular branch in github, then it is probably safe (or at least safer) to use it from there. Otherwise, I would assume that the Moodle plugins directory is the place to find the stable code (after all, that is where Moodle itself downloads plugins from, if you install plugins directly from the Moodle admin UI - it does not support downloading plugins from their associated github repositories).
དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (3)
In reply to Visvanath Ratnaweera

Re: Versioning and Deprecation changes

Johannes Burk གིས-
Core developers གི་པར Plugin developers གི་པར

Since I like managing things with git I'd love to see every plugin using some consistent model which links stable releases to specific commits. But I don't think it is desired or even possible to force plugin developers to something. 

My idea is to recommend git as the source control system for plugin development and make some recommendations regarding versioning, branch naming and tag usage. I know that it is not safe to assume that the latest commit of something is stable. Therefore I would always recommend to use git tags for releases. The Moodle plugin directory already supports linking a plugin version to a VCS tag! Additionally a stable branch per series could help finding the correct version when working with git only. When a developer takes "stable" branches serious (and makes use of the feature branching model) then it should be safe to use the latest commit of such a stable branch. And since branches are cheap why not use multiple branches pointing to the same commit if nothing on the plugin side changed between two or more Moodle series. 

What I'm currently missing is a recommendation for a human readable plugin version ($plugin->release). ... And a wider adoption of $plugin->supported, $plugin->incompatible and the specification of a VCS tag in the plugin directory. 

Regarding the discussion about the LTS version: I think making the last version per series LTS is the right decision. But I still vote for a longer general support window. ;D

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།:Useful (2)
In reply to Matt Porritt

Re: Versioning and Deprecation changes

Séverin TERRIER གིས-
Documentation writers གི་པར Particularly helpful Moodlers གི་པར Testers གི་པར Translators གི་པར

Hi,

Just a question about deprecation, to be very clear. You indicate that things deprecated before an LTS will be deleted in the next major version (the new Series).

But if i understand well, and in my logic, it is things deprecated before and in an LTS, that are deleted after that.

Another way would be to indicate that things deprecated in a Series are deleted at the start of the next Series, so each new Series start clean (of old things).

Am i right ?

Séverin

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Séverin TERRIER

Re: Versioning and Deprecation changes

Andrew Lyons གིས-
Core developers གི་པར Moodle HQ གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར Testers གི་པར

Just a question about deprecation, to be very clear. You indicate that things deprecated before an LTS will be deleted in the next major version (the new Series).

Correct.

But if i understand well, and in my logic, it is things deprecated before and in an LTS, that are deleted after that.

Incorrect. Anything deprecated in the LTS will not be deleted until after the next LTS.

Another way would be to indicate that things deprecated in a Series are deleted at the start of the next Series, so each new Series start clean (of old things).

Whilst that would be great for a clean series start side of things, it makes it harder to upgrade form LTS to LTS.

དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -