Always allow downloading and installing contrib module dev-release in next major version

A strong -1 from me.

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 this is not a solution I would want.

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.

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

That's more or less the same thing, 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.

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 are going to care about publishing and maintaining 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.

... 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.

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

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 📌 Add a composer plugin that supports 'composer require-lenient' to support major version transitions Active 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 📌 Add a composer plugin that supports 'composer require-lenient' to support major version transitions Active :

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.