Problem/Motivation

Drupal 7 has so far been been supported for 12 years (2011-23) and Drupal 8 was supported for six years. But the current life span for major releases is much shorter:

Version  Released  Years supported
7        2011      12 
8        2015      6 
9        2020      3
10       2022      ?
11       2024      ?
12       2026      ?

From Drupal core release cycle: major, minor, and patch releases

With the current pace of major version releases, there's a lot of playing catch-up for contrib module maintainers and users.

Even fairly popular modules installed on hundreds of web sites were quite late to start preparing for Drupal 10 and get a stable release. Some are still not downloadable or installable on Drupal 10, even with Drupal 9 being EOL in six months as of today (May 2023).

This blocks faster adoption of the next version, is frustrating for current and potential Drupal users, and becomes a stumbling block for wider Drupal adoption, making us lose users.

Allowing dev-version of contrib modules to be installed could yield these benefits:

  1. Lowering the bar of entry (download+install in next release) would result in more activity in the issue queue
  2. These issues could be reviewed by the community
  3. This would be a big help for the maintainers, and could be the nudge needed to review and commit and make it Drupal 11 ready

If there are no "Drupal 11 readiness" issues (or few with little activity) it can much more easily stay off the radar of the maintainer, who can more easily forget about it. If there were oven-ready RTBC patches, it would be a big help.

Proposed resolution

Always allow downloading (Composer) and installing (Drush/GUI) the dev-version of a contrib module in the next major version. The contrib module maintainer shouldn't have to do anything, it should be the default, and happen automatically.

This would yield several benefits:

  • It's much easier to install any contrib module, so bugs and new features will get more eye balls, and get fixed sooner, making sure the contrib module is ready well in advance, when the next major release becomes the official release
  • Users who want to build a web site with the next major release are not blocked from installing the contrib module, without resorting to Composer plugins and versionxx--readiness-patches

Allow installing dev-release in next version, models:

  1. Automatically append the next major release in contrib_module.info.yml file:
    • # From
core_version_requirement: ^9.2 || ^10

    • # To:
core_version_requirement: ^9.2 || ^10 || ^11

    • # ... or even?
core_version_requirement: >=10
  2. Have 2 dev-releases:
    1. The current dev-branch, which goes to stable
    2. A next-version-release branch for preparing, sort of a pre-dev?

    This would add extra maintenance and complexity for module maintainers ...

  3. ?

Remaining tasks

  1. Decide if it's a good idea or not
  2. If yes, decide how to implement it

User interface changes

API changes

Data model changes

Comments

ressa created an issue. See original summary.

ressa’s picture

ressa
he/him
commented
Issue summary: View changes
ressa’s picture

ressa
he/him
commented
Issue summary: View changes
ressa’s picture

ressa
he/him
commented
Issue summary: View changes
ressa’s picture

ressa
he/him
commented
Issue summary: View changes
gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

A strong -1 from me on the first model proposed.

The core_version_requirement key is what the module's maintainer must use to indicate what version(s) of Drupal the code base is compatible with. If the next major release is added to this key automatically (i.e. without requiring judgement by the module's maintainer), composer may haphazardly add incompatible code to the project's code base, potentially breaking the site.

One of the major features of composer is to not let a site builder add anything to the project's code base if it is not certified compatible with what's already there. By manipulating the core_version_requirement key to pretend that any dev-release is compatible with the latest major version, without any human oversight and QA, composer is no longer useful for this.

I understand it is annoying when a project's maintainers are dragging their feet to put out a version certified as compatible with the next major version (and I've also noticed that this is happening a lot), but implementing a hack that would effectively prevent composer from doing what it is supposed to do, is not something I would want to happen.

As for the second model (having two alternative dev-release), it would, as noted, add extra complexity for module maintainers. I don't think it would be used much, if at all.

ressa’s picture

ressa
he/him
commented

Thanks for weighing in @gisle. If manipulating the core_version_requirement key is a no-no, another option could simply be to decide that the dev-version is set to core_version_requirement: >=9.2 always?

Or option #2 which I proposed: That an extra dev-version is created, "A next-version-release branch for preparing, sort of a pre-dev"?

It could also be a third method, we just haven't thought up yet ... If you were to dream, what could you imagine would help overcome the upgrade bottle necks in the future? This is a real problem, as you also acknowledge.

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

another option could simply be to decide that the dev-version is set to core_version_requirement: >=9.2 always

That's even worse. And locking it at >=9.2 seems rather arbitrary. Further down the road, a maintainer may want to leverage on PHP 8.2 (or something else incompatible with Drupal 9.2), and things will break. The fundamental problem with the first model is that doing this will stop composer from preventing site builders from shooting themselves in the foot. The fundamental problem is that if the code base is not compatible with a particular version of Drupal, just stating that it is, is not going to make it so. Is it really an improvement to let make the installation frictionless, if doing so ends up breaking the site?

As for the second model, I don't believe that maintainers that can't be bothered with putting out a single release compatible with the next major version will publish and maintain two alternative releases.

If you were to dream, what could you imagine would help overcome the upgrade bottle necks in the future?

There is already the abandoned project process. There is also a community effort to leverage on this, see: Adopt contributed projects for Drupal 10 readiness. I believe getting a larger part of the community engaged in adopting projects to make them Drupal 10 compatible is the best path forwards. I've also created this: #3357734: Lower the bar for module adoption for Drupal 10

ressa’s picture

ressa
he/him
commented
Issue summary: View changes
Parent issue: » #3238652: [policy] Decide how long major Drupal versions should be supported
Related issues: +#3357734: Lower the bar for module adoption for Drupal 10

... locking it at >=9.2 seems rather arbitrary. Further down the road, a maintainer may want to leverage on PHP 8.2 (or something else incompatible with Drupal 9.2), and things will break.

You're right, >=9.2 in the minimum example was a bad choice, it should be just the current release and onward, core_version_requirement: >=10. I have updated the Issue Summary.

The fundamental problem is that if the code base is not compatible with a particular version of Drupal, just stating that it is, is not going to make it so. Is it really an improvement to let make the installation frictionless, if doing so ends up breaking the site?

I partially agree, but from my perspective, code in a dev-branch is in flux by definition, and using it can break things. Ideally, dev-branches shouldn't be used in production. But if you want to install dev-branch of a module in a future Drupal release, with the risks involved, you should be free to do so.

From my own observations, changes between 8>9>10>11 are often PHP deprecations which only result in warnings, and are not break-the-site level. But of course, they can be.

As for the second model (having two alternative dev-release), it would, as noted, add extra complexity for module maintainers. I don't think it would be used much, if at all.

Yeah, you're probably right.

And thanks for listing the Drupal 10 readiness initiatives, I appreciate the efforts by you and the community.

Allowing dev-version of contrib modules to be installed could yield these benefits:

  1. Lowering the bar of entry (download+install in next release) would result in more activity in the issue queue
  2. These issues could be reviewed by the community
  3. This would be a big help for the maintainers, and could be the nudge needed to review and commit and make it Drupal 11 ready

If there are no "Drupal 11 readiness" issues (or few with little activity) it can much more easily stay off the radar of the maintainer, who can more easily forget about it. If on the other hand there were oven-ready RTBC patches, it would be a big help.

catch’s picture

catch
he/him
Primary language English
commented

I think this probably a duplicate of #3267143: Add a composer plugin that supports 'composer require-lenient' to support major version transitions.

ressa’s picture

ressa
he/him
commented
Status: Active » Closed (duplicate)
Related issues: +#3267143: Add a composer plugin that supports 'composer require-lenient' to support major version transitions

I believe you're right, thanks @catch!

I can see that I bookmarked @japerry's Navigating core_version_requirement last week, and shortly after that tried the Drupal Lenient Composer plugin. That issue must have been lingering in my subconscious :)

The Drupal Lenient Composer plugin is great, really. But I think we shouldn't force Drupal users to add and configure Composer plugins, and so created this issue. Especially not beginners.

I am glad to see that there was consensus in #3267143: Add a composer plugin that supports 'composer require-lenient' to support major version transitions on more or less one of the suggestions here and what @japerry suggests in his blog post:

My personal preference is to work with the next ‘beta’ of a major version. That allows developers to immediately work with a module, but doesn’t allow it to automatically work with the next stable release:
[...]
If your module supports Drupal 9 and 10:
core_version_requirement: >=9.2 <11.0.0-stable

From Navigating core_version_requirement.

The Proposed resolution in #3267143: Add a composer plugin that supports 'composer require-lenient' to support major version transitions:

Proposed resolution

Everywhere we document core_version_requirement, suggest >= for core version compatibility to remove the upper version compatibility bound. Document the pros and cons, as well as alternatives and their pros and cons.

This will occasionally result in modules being declared compatible with new major versions of core when they're not, but this seems like a much better problem to have. If the module does not work, it already didn't, so the site owner is no worse off. Tools like Upgrade Status are available to help the site owner detect modules that have issues

Even then, it looks like the Composer plugin route was chosen, according to the title ... I would have preferred having a minimum and maximum model recommended, to lower the barrier.