This is an issue I have been suggesting for many years but after discussions with a range of people I'm going to try and formalise it some more.

The problem

At the moment, Moodle's versioning is somewhat eratic and meaningless. For reference I'll use the following example and terminology:

Moodle 4.1.2

       │ │ └── minor version

       │ └──── major version

       └───── yolo version

We have an ever-increasing major version number, which gets periodically reset to 0 when we do a yolo version every so often. There isn't much ryhme or reason to when we do this - just when someone decides that it's about time. So far that's been 1.9 => 2.0; 2.9 => 3.0; 3.11 => 4.0.

Beyond this, there is no special meaning to the first number versus the second number. They may as well not exist and just be a 41.2, 41.3, and so on.

At the same time we have a number of other concepts, and features which happen to versions, but not in a meaningful, or consistent way. These include:

• LTS releases. These typically happen every 24 months. Examples include:
  • 4.5
  • 4.1
  • 3.9
  • 3.5
  • 3.1
  • 2.7
• deprecations. These happen in one release, and then have a rolling 'final' date
• compiled JS changes

Ultimately this becomes very confusing for both administrators, and developers. It is never clear when a version is an LTS release, when some deprecated feature will be removed, etc.

I would like to propose that we rethink our versioning strategy, and make it more meaningful. We should combine our versioning with our LTS cycle, and combine our LTS cycle with actions such as deprecations.

The proposal

I would suggest that we use the following terminology:

Moodle 5.1.2

       │ │ └── minor version

       │ └──── major version

       └───── series version

I would propose the following rules:

• the LAST release in each series MUST be an LTS release
• the next major release after an LTS release MUST be at the start of a new series

That is to say:

• Series 4 (Current series but transitional to the new versioning scheme):
  • 4.1 (Current LTS) => 4.2 (Current release) => 4.3 (Future release) => 4.4 (Future release) => 4.5 (Future LTS release) - 4.5 is the last release in the 4.x series
• Series 5:
  • 5.0 (Standard release) => 5.1 (Standard release) => 5.2 (Standard release) => 5.3 (LTS release) - 5.3 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 (Standard release) => 6.4 (LTS release) - 6.4 is the last release in the 6.x series

Note: The above are just examples. We do not expect there to be a 6.4 - this is just to exemplify that if there are more than the standard 4 releaes per series, then the final version is always the LTS.

From this point we then start to tie breaking changes to the LTS series.

Deprecations

Deprecations currently follow a rolling two-year period. This means that we are constantly seeking deprecations and have to work out what their deprecation cycle is in order to process the secondary stages. For example, a function initially deprecated in Moodle 3.11 will be finally deprecated in Moodle 4.3. This means that we have to keep track of the deprecation cycle for each function, and then work out when it will be removed. This typically happens by followup issues created at the time that the initial deprecation was made. There is no easy way to 'discover' this information from the codebase.

This proposal ties the deprecation processes to the LTS cycle and significantly shortens it in many cases. I would propose that:

• any method/function/feature that is deprecated prior to an LTS release, and which emits debugging is converted to throwing an exception in the First major release of the next series (e.g. 5.0.0).
• anything that currently throws an exception is removed in the Second major release of a series

For example:

This change will mean that we can more readily identify any feature deprecated in a given series, and process it to the next stage (throwing an exception) in a single location without the necessity of having a secondary tracking issue. Then in the following release, they can be removed entirely.

Compiled JS

Unfortunately our current reality is that we have to compile JS as developers and include it in our shipped products. This applies both to Moodle core, and community plugins. That is unlikely to change any time soon but it does present some difficulties. The primary difficulty is that sometimes our built files will be modified for a range of reasons, including:

• changes to our minification tooling
• changes to our NodeJS dependencies
• changes to our browser compatability lists

When this happens it has a tendency to frustrate developers and make a bit of a mess of everyone's CI systems. To alleviate this, we currently try to:

• reduce the number of times we make such changes; and
• when such changes are made we apply them to all supported branches.

There is currently no rule, rhyme, nor reason, about when we do this.

I would propose that we tie these changes to the series cycle. That is to say:

• Any change to built files will be applies to all releases in the same cycle (for example 5.x)
• Ideally, and where possible, any change to built files will be applied at the start of the next series (for example 5.0.0)
• Browser compatability is selected at the start of a series and will not change during that series (that is to say it is 'pinned')
  • in the event that the pinning is not updated at the start of a series but a change is made during the series, the change will be applied to all releases in the series. This may happen if the built files are changed for other reasons such as a necessary tooling change which cannot be avoided.

Rationale

These proposals are intended to make a number of things clearer and more consistent, namely:

• When a release is an LTS release
• When a feature is deprecated, what the removal timeframe is going to be
• When compiled JS will change
• When browser support will change

It also has the benefit of reducing cognitive overhead, especially when determining when deprecated items can be acted upon.