[Meta] Determine how available updates for modules should be handled if they are not compatible with the current version of Drupal core

We cannot tell if a module is compatible with an end users system, *even if* we had someway to verify that at least *core* is compatible.

Core is just another dependency in a module's dependency chain, so in the example in the IS, we could have :

• 1.2.0 that is compatible with Drupal ^8.8 and 9 and *also* introduces a new dependency on another contrib module

We really don't have any way of knowing whether the end user has that module or not externally.

So, its my opinion that we should treat the modules updates page somewhat as a combination of how composer update --dry-run and composer outdated currently function.

composer update --dry-run shows you what your site could upgrade to, given your existing dependency tree. It would typically only show updates that matched the major api of the existing module (i.e. 1.2.0->1.3.1).

composer outdated will show you *anything* that is newer than your currently installed module. (so 1.2.0 would show 2.0.0-alpha1 as an option). I think it would be useful to see that there may be new, backwards incompatible modules available. but not necessarily recommend them.

Finally, since we are now marking releases of projects as insecure/unsupported, that can happen regardless of a modules compatibility options, as the assumption is that its installed.

I think there are two problems here:

1. We want Drupal 8 to keep backwards compatibility in how it works. Yes, it does not care for the whole dependency tree (PHP version you are running, other Drupal modules, outside dependencies that may be conflicting with yours and not even core minor version compatibility from info files). Assuming an 8.x-3.2 module could be only 9.x compatible we can only keep Drupal 8 feature backwards compatibility if we add additional data to the update info so those could be filtered out locally.
2. The second question area is what we want of future Drupal. Update module has become less and less useful exactly because it cannot check most of the dependency tree, it only checks Drupal core compatibility and done. It cannot catch if a module has a new Drupal dependency or you also need to update core to use the new module version, etc. So we need to define what we want out of update module in Drupal 9 and going forward and also consider what data we need for that.

I think 1 and 2 likely will be different solutions, but I have no doubt that 1 needs additional data in the update feed for backwards compatibility of Drupal 8.

We had a long discussion in slack about this, and I'd like to reiterate some things here:

I don't believe that there is any backwards compatibility that we need to keep compatibility with. There is currently no mechanism for determining whether or not a potential update can be installed on a users site. The only thing we are doing currently is assuming, that because the update came from the 8.x url, that it is compatible, because CORE_COMPATIBILITY = 8.x.

But that's not really the case at all. Modules may add new dependencies in updates, modules may add dependency constraints on drupal:system(>8.8), modules may add or change composer requirements. They might add php requirements as well, like a new php extension or a php version floor. A module may coincidentally be compatible with core, but it can just as likely be not compatible. (I just checked and theres about 264 d8 modules with *some* constraint on drupal:system.)

So from a UX perspective, whats the ideal experience for a user if, say they have a drupal 8.9 site, that cant quite convert to 9.0.0 yet because theres a couple modules that haven't yet converted deprecated code, and updates for some other modules they use start to appear that are 9.0 only because they use some symfony 4/5 apis. What should that user see?

1. What they would currently see now, that there is an update for their module
2. Show that an update is available but with a message that their site isn't a high enough version to use it?
3. Not show the update at all

The first scenario means a user downloads the module, and attempts to install and gets told its incompatible, or they attempt to download with composer, but cannot, because dependency resolution wont allow it.

The second scenario is possible if we provide the core_version_requirement/core_compatibility data in the updates, but the *only* thing it is capable of handling is core itself. Anything else would still act like there's an update

The third scenario seems like we'd be hiding useful information from the user.

So I guess the question is given all the ways that a module can be incompatible with a users site, is it beneficial to have the updates report warn about core compatibility (since it is the most likely way a module will be incompatible), with the understanding that we cant know the rest of the dependency picture and that we might still be telling folks that an incompatible update is available?

Or would it be better to consistently tell users of available updates and let the install process handle the compatibility restrictions?

fwiw I agree with @mixologic in #5.

Update status' approach is currently to tell you about any available update whether or not it's actually compatible with your site, but this allows you to then go and read the release notes for that version etc. (obviously not everyone does this).

The opposite approach to this is composer's, which if it finds an incompatibility will not inform you at all that it isn't updating, but silently keeps you on your current version. You can just about find out why you're not getting updated by using composer why-not but IME the experience of this is really bad.

For security releases, or when a version of a module goes unsupported, I think we really do want to inform people about updates even if the update is not compatible with their current version, because they still need the information and should get themselves in a position to be able to update. For normal updates, we still should lean towards telling people about updates because the longer we don't, the more likely they'll end up on an unsupported release / hit by a security release they can't update to yet.

So while it would be good for the UI to be able to inform people of likely problems, I do think the current situation while imperfect, is a better compromise than what composer does on the command line and it is likely to be very, very difficult to bridge the two.

Ahh, I just found this issue. I posted some comments at #3074993-16: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates that probably should have been in here.

...
However, all this code is going to get much more complicated, since there's no way for update.module on your site to know everything about the requirements/compatibilities/etc of all the future releases coming down those feeds. This whole system was designed ~14 years ago when contrib was totally locked to specific versions of core. Now that we're breaking that assumption, update.module is going to have a really hard time keeping up.

e.g. I'm running token 3.2.5 on 8.9.3 core. Token 4.0.0 is released, which is only compatible with 9.1.x and up. How will update.module know that? What's it going to tell me? That a new release of token is available, but I better click on the release notes and read the fine print? Or are we somehow going to teach update.module all about the dependency web of everything? Or do we hope that all contrib maintainers everywhere actually implement SemVer properly, and update.module never recommends (blindly) that you jump major versions? Or what?

We're getting into the territory of Wrong Tool For the Job(tm).

Either we're going to find ourselves re-implementing all the dependency reconciliation logic of composer, or we're going to have a system that gives people bad advice.

Or we're going to realize that update.module has served us well for a long time, but maybe should now be put out to pasture.

Perhaps we should focus on the composer initiative, and have a UI that talks to that, and can give you a report of what would happen if you did a "composer update"...

Love you, update.module. You were probably my biggest contribution to core. But maybe you need to die. ;)

So, uhh, yeah, agreeing with @Mixologic in #5. I'm really not sold that all this effort is worth the trouble. I think end users would get more benefit from the composer initiative, and putting something like a UI around composer update --dry-run and friends.

So, one end goal on the "someday, it would all be awesome" horizon for the composer initiative is that composer could become the dependency managment/updates interface entirely for core, maybe targeting Drupal 10.

The primary issue with that is composer currently uses *far* too many resources in both memory and cpu to be something we can wrap a web request ui around at the moment. (like gigs of ram and minutes of processing)

We wont be able to even think about doing something of that nature until we've fixed the performance problems with composer - which, there is a lot of work going into looking at ways to do that - but those are all a long ways off (composer 2.0, and many other architectural issues with composer, that are difficult to fix).

So, updates module will likely be around for another few years, so we're going to have to make a best effort to making it usable.

Given that I think Ted's suggestion here:

This is not as simple as checking core: 8.x anymore because of core_version_requirement but I think we could do something like \Drupal\Core\Extension\InfoParserDynamic::isConstraintSatisfiedByPreviousVersion() if drupal.org provided the core_version_requirement value for releases

Would probably be the way to go to handle things like your aforementioned token module situation.

We're now storing the core_version_requirement so we have that data available to put into the metadata: https://www.drupal.org/project/project_dependency/issues/3084046

Unfortunately there is not composer method to call to determine if something is only compatible with the next major version of project.

There might be.. composer outdated --minor-only exists. More here: https://getcomposer.org/doc/03-cli.md#outdated

--minor-only (-m): Only shows packages that have minor SemVer-compatible updates.

we can unpostpone https://www.drupal.org/project/infrastructure/issues/3074998 and add the data there, as long as we all understand that data cannot be used for anything more than informing a user that their core version is too outdated for the update. (i.e. not use it to *filter* anything out)

Ah, yes, I guess I was more thinking -> lets look at the composer source and see what its doing to handle --minor-only except do something potentially similar for 'next major, vs, lets use composer to do this.

Whenever there are questions about how things ought to work, it's sometimes helpful to look at what other applications do, because those can help inform user expectations.

Apple handles notifications of new OS versions separately from updates of the "apps" that are installed. I can go to About this Mac > Software Update... and see that macOS Catalina exists...

...but in my App Store updates, I only see updates that are relevant to my currently installed OS:

(I know this is true because I have an iPad that is older than dust, and only a small handful of the apps on it show updates available, despite my newer iPhone has updated the same applications several dozen times over the past few years.)

Chrome / Firefox would be other good programs to check the workflow of, but I personally can't do that because I have automatic updates enabled, and therefore nothing is out of date. ;P But they too also handle the "platform" version update separately from the "extension" version updates.

I don't have access to a Windows machine to see how they do it, but that'd be another place to look for inspiration.

Drawing from those examples, though, I think the user stories to satisfy would be:

- As a site builder, I expect the list of available updates to be limited to only those that will work with my (minor, preferably; else, fall back to major) version of Drupal.
- As a site builder, minor/major version updates are Kind Of A Big Deal™ so I don't want to be distracted with thinking about them until I'm in the right headspace/have plenty of time in front of me/etc.
- However, as a site builder, if a security problem exists that can only be rectified by increasing my minor/major version of Drupal, I DO expect to be notified of that. (Because otherwise how could I possibly know?)

^ I'm not sure how feasible those stories are to fulfill, since we'd probably rather not re-implement Composer in Update module. :P But it does make sense to me that those would be the expectations, based on how other update notification systems that people are likely to have interacted with every day work.

I guess I'm surprised that hacks like drupal:system (>8.8) are still needed/supported; I figured core_version_requirement would be flexible enough to handle those kinds of requirement increases. If it did, that would make the first user story much easier to address, I would think? (if (!empty(core_version_requirement) { ... use it ... } else { use "core" value })

As far as new dependencies/requirements that get added in in an update that "appears" to be compatible with your system, I don't think that's a huge deal; even with a routine app update on your OS, a newer version of some library could be required, or some other manual thing you need to address prior to updating. Not validating for this is also a "pre-existing condition" in HEAD.

I think some combination of @tedbow's plan in #11 and @webchick's UX ideas in #15 could work well. Maybe in two steps?

First of all get core_version_requirement into Drupal.org release information and then show it in the existing update status UI.

Then an UX something like this:

1. Security updates (all)
2. Contrib patch and minor updates (compatible)
3. Core minor or major updates

However one issue is that while software update processes only show updates you can do and major updates separately, the major updates when they run will always include all your dependent code as well. i.e. if I do an ubuntu major update, that update will include updates to everything else I have installed (at least stuff from the official repositories) without me having to go back and separately update them.

For us a core minor or major update may or may not require an update to contrib modules and we're assuming a manual process still. So we would probably need to do:

1. Security updates (all)
2. Contrib patch and minor updates (compatible)
3. Core minor or major updates AND contrib updates that require the newer version of core.

One thing worth noting is @drumm's comment here: https://www.drupal.org/project/drupalorg/issues/3074998#comment-13350246

Projects are what get security updates, and yet Drupal deals in modules, and has a somewhat convoluted way to imitate turning a module back into a project. We'll have to do some of the same sort of thing of turning *module* requirements into *project* requirements. And hope that maintainers don't do weird things like have different core_version_requirement set to different values within their project.

eg:
http://git.drupalcode.org/project/drupal/blob/8.9.x/core/lib/Drupal/Core...

I haven't had a chance to process the rest of that comment, but just quickly:

To me showing only updates that are compatible with the minor version of Drupal core that is installed does not seem better than showing contrib modules that are compatible with my major.

What I meant is that if I'm on Drupal 8.6, and there's a (non-security) module update that requires a minimum of Drupal 8.8, I should not see that update in my list. Because then it's just teasing me. It's not actually an option to update to until I complete my D8.6 => D8.8 conversion, which might be several weeks/months from now, and will happen entirely independently of me upgrading, say, Paragraphs module.

If we show all updates regardless if they're compatible or not, we unnecessarily bloat my "you need to update this stuff" dashboard with non-actionable clutter, which is defintely not ideal, because it then teaches me to ignore update notifications as meaningless noise, when most of the time I should actually really care what's in there and making sure I'm on the latest (feasible) version of the code, esp. in order to make my eventual move from D8.6 -> D8.8 much less error-prone.

What I meant is that if I'm on Drupal 8.6, and there's a (non-security) module update that requires a minimum of Drupal 8.8, I should not see that update in my list.

The one problem with this though is that the version that requires Drupal 8.8 might also be the only version of that module that's compatible with Drupal 8.8. So when you actually do want to update to Drupal 8.8, we should show that there's also a contrib module update to do at the same time. This could be in a different list somewhere but I think we should try to avoid telling people they only need to update core, then after they've update either their site doesn't work at all due to module incompatibility, or they get a tonne of update notifications they had no idea about.

I do think we have to keep in mind things we do now that might stop us from making changes later because they will be consider too big of BC or user facing changes.

The update status controller isn't an API, so we should be able to make whatever changes we want to it.

Even if we decided there was some kind of backwards compatibility issue, there could be a new/old UI switch or an experimental module or some other way to gradually replace it.

+1 to not printing the raw semver constraint, and instead showing actual version numbers.

-1 to showing *all* possible core releases a given thing is compatible with. If you're 6 months behind schedule (which is totally legit and normal for a ton of sites), it's going to be super overwhelming noise on the update report to see

This module is compatible with Drupal core: 8.9.0, 8.9.1, 8.9.2, 8.9.3, 9.0.0-alpha1, 9.0.0-alpha2, 9.0.0-beta1, 9.0.0-rc1, 9.0.0-rc2, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.1.0-alpha1, 9.1.0-beta1, 9.1.0-beta2, 9.1.0, 9.1.1, ...

next to most of your installed projects...

If there are exceptions, either:
a) Punt, assume the user isn't going to jump to a less-than-latest version. If they do, they'll find out it's incompatible then.
b) Figure out the exceptions (if any) and put them in some hidden pop-up thingy?
c) Figure out the exceptions (if any) and put in a generic "Some exceptions found, please use the latest available release" (more or less).

p.s. Ugh, I just realized. We're telling contrib maintainers that we suggest they use this:

core_version_requirement: ^8 || ^9

Which is going to match 9.1.0, right? How do I know now, when tagging my contrib module's next release, if it's still going to be compatible with 9.1.x? I have no friggin' idea. It's probably going to be wrong by then. At most, shouldn't we be recommending folks do:

core_version_requirement: ^8 || ^9.0

?

It seems like we're winding towards a proposed resolution. When we have it we should make sure it's reflected in the issue summary, since this comment stream is rather dense. :)

The proposed solution and

This module is compatible with Drupal core: 8.8.3 to 8.9.1

looks good to me.

I think we should try to get this into 8.8.0 right up until and during rc.

The other option would be to add core_compatility to the current */8.x/* feed from Drupal.org.

I deployed this earlier today, #3074998-29: Add explicit information about core compatibility to update data, and all update status XML should finish regenerating in 20 hours or less.

Is this now a duplicate of #3096078: Display core compatibility ranges for available module updates? Or if not is what's remaining here critical?

The backport party for step 1 is now complete! 🎉 Removed all that from remaining tasks.

Fixed some spelling errors, grammar errors, and other minor updates to reflect current reality.

I don't believe this plan still needs to be critical. The critical pieces are either already done, or there's an existing critical issue open (e.g. #2991207: Drupal core should inform the user of the security coverage for the site's installed minor version including final 8.x LTS releases which is now RTBC). Downgrading to major for now.

Thanks,
-Derek

What's still in scope here that's not already covered by the outstanding issues in #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core, and allow modules to be compatible with Drupal 8 and 9 at the same time?

Updates that are listed under "Not compatible" on admin/reports/updates/update should not cause the status report to have a "Module and theme update status" "Out of date" warning so long as there is still a supported version installed.