Display local and remote Drupal 9 readiness status (based on update and info.yml info)

My recent pet complaint w/ D9 compatible modules is many don't have a tagged release. This means for my 30 or 40 contrib modules on a site, I'm stuck with using a 1.x-dev, 2.x-dev, dev-master, etc, as version for the module. For a handful of modules, that's not a big deal. But when I have half of my contrib modules all needing a dev-master version, that makes keeping stability for the module an issue. It would be _really_ nice if this, "I'm D9 compatible" column would spit out if it is on the dev branch or a tagged release. And somehow incentivize contrib authors to get a red X turn into a green checkbox and show the module has a tagged D9 release.

@heddn: Upgrade Status only gets data from Update module in core, which uses update XML from drupal.org which will contain only tagged releases. So we can only do the data gathering for update recommendations either way with tagged releases.

Is there a way to put a red X then if the module doesn't have D9 support? That way it incentives people to switch from red x to a green checkbox?

Testing welcome on this :D Also UI suggestions for making it brief. This will use a lot of screen real estate applying to various projects.

Thanks @dww for pointing to the simplest solution to base this off of data we already have. Whew!

+++ b/src/Form/UpgradeStatusForm.php
@@ -349,15 +350,24 @@ class UpgradeStatusForm extends FormBase {
+          $drupal9Compatible = [];

It would make things more complex, but could we have a red "Not Drupal 9 compatible" too? That would make me want to get from Red to Green.

I don't think we should make "Up to date" a link because when you are up to date, there is no need to go to the get informed about the release. Here is a slight rework where the "Up to date" remains a simple text item. Also swapped the !Semver to Semver because we were testing the opposite condition :D Thanks @shaal for pointing that out yesterday on chat.

Ok I realized that this brings in a competing status thing into the table. Normally the whole row is colored based on the local result and an icon is displayed based on the local result. That is not really the primary information I guess once/if there is a Drupal.org sourced update that fixes it for you. Then you would not really care for the problems found locally. So this puts unneeded emphasis on the status icon and row color. So I decided to unify the status icon usage and made rector be a column as well for consistency. I also updated the column labels from "Available update" and "Status" to "Drupal.org update" and "Local status". The patch would also be local status of sorts, so not sure how to express that properly, this is a work in progress. Then I made the Drupal 9 readiness of the update available a primary information. You don't really care about the version number of it I guess, but that it would be 9 compatible. So made that the primary info:

The upgrade rector counterpart is at #3150871: Re-integrate with Upgrade Status, since the 3.x form is not supported, it moves the patch result from a badge/label that does not necessarily look like a link that does something to a proper table column.

Beautiful!!!

Discussing this with Shaal on slack. We both realized that it is not shown without a scan if your current version is already Drupal 9 compatible or not. That should also be mostly available from the extension info that we are using, so we can display it. At that point the data will become even more unwieldy so we'll need to figure out how to approach this on the UI. I would love to take another holistic look at how to make the UI useful instead of just dumping a bunch more data at you. One thing Shaal suggested is to implement a "Suggested next step" as the primary UI element on projects and let the user see the supporting data if they desire. That would dramatically simplify the UI but also dramatically redesign it :D

I think with the new realities of usually remote updates available to projects as well as likely existing issues on the projects (from rector, etc), we should direct people towards those. Local scanning is still a very important piece but should not be the primary driver as much work is already done on drupal.org either as an updated release or work in issues.

Here is the missing feature of checking the local version first. Did not bother too much with the UI part, just adding a party popper for now as we are discussing how to redo the whole UI. I think this now has all the checks we need, but the UI reorganization is still to be done.

Committed this to a new 3.x branch, so we can iterate on it instead of in one issue/patch. Thanks!

Surprised you didn't use 3.0.x for the new branch. ;)

We don't need to rule out people using Drupal 8.7 to get the benefit of this tool.

Ahh, right. Good point.