6.x contrib update status plan

Sounds good to me. It aligns with what we discussed AFAIS.

1. I don't agree with this plan. Showing a "security update required" message when there is no security update available is bad user experience and also might make it harder for people to see actual security updates (if there are any) - has that been tested?

   We've always used the "Not supported" status for this situation (e.g. Services module for Drupal 6 was marked unsupported a long time ago and certainly has unfixed security issues by now given that there have been Drupal 7 security releases). I don't see the problem with it. I think the possibility of unfixed security issues is exactly why Update Status marks these modules red in the first place.

2. Note that it may be possible to do a variation of the "simple option" from #2675892-36: Drupal 6.38 isn't correct in Update Status, it is unsupported and will be insecure in the long run for contrib modules instead. I haven't tested it but I would guess it may work if the XML looked like this:

   <supported_majors>999999</supported_majors>
   <recommended_major>999999</recommended_major>
   <default_major>999999</default_major>
   

   (where "999999" is some number so large that no module will actually have a release branch for it)

3. Contrib XML will be hard coded to link back to the LTS landing page

   I commented in the other issue why that's not the best place to link to, but especially for contrib modules - why would we do that? This would just prevent people from getting to the project page for the module.

   I think any custom end-of-life messaging could be handled via the Drupal core entry on the available updates page, so I don't see why it would need to be done for each contrib module in addition to that.

4. If we want to change the link at all, one useful possibility would be to have it go to the "All releases" page for the module, filtered for Drupal 6 releases (example: https://www.drupal.org/node/106016/release?api_version[]=87). If desired there could even be end-of-life messaging added to that page.

@drumm, they are almost equivalent in the case where the module is up to date, but if the module is not up to date (e.g. FileField 6.x-3.13) then I think the first approach shows "Security update required" whereas the second still just shows "Not supported".

So it depends exactly what we're going for here, but in the other issue I think people were pretty interested in still being able to see which of their modules had security updates available.

I tested this with the attached (which is based on #2675892-36: Drupal 6.38 isn't correct in Update Status, it is unsupported and will be insecure in the long run but for filefield rather than core). So it's not the same as actually changing the XML, but should have the same effect.

I just debugged it now and the reason it gets marked as a security update for me is that this code adds 6.x-3.14 to the list of unapplied security updates and then this code marks the project insecure as a result.

The outcome in #18 seems great to me.

One thing I did notice is that for certain modules (Views and Ctools are both examples) if you are running the latest version, Update Status is now showing "No available releases found" for those, rather than "Not supported" like for other modules.

Not sure what the reason for the difference is, but in any case, if you are running an old enough version (such that a security update is available) it still shows the security update message, so I guess it's good enough.

Actually for some modules (CCK and Pathauto) there's a worse problem; in those cases you can be running an insecure version and it still shows up as "not supported" rather than "security update required".

Not sure what the difference is; maybe because those modules have multiple branches but most sites are on the older branch? (I.e. the problem shows up on the older branch, 6.x-2.x for CCK and 6.x-1.x for Pathauto.)

Actually the problem may be simpler than that. Both CCK and Pathauto have <project_status>unsupported</project_status>:

https://updates.drupal.org/release-history/cck/6.x
https://updates.drupal.org/release-history/pathauto/6.x

which is different than e.g. FileField:

https://updates.drupal.org/release-history/filefield/6.x

Seems to me that defeats the purpose of what this issue was trying to accomplish.

Do we know why they are set like that?

I spot-checked a few others and it actually seems widespread. Some, like Views Bulk Operations, are not only marked "unsupported" but also have all releases except the most recent one unpublished, which would make it doubly hard for Update Status to ever report that security updates are available for them:

https://updates.drupal.org/release-history/views_bulk_operations/6.x

I cross-posted, but:

After the initial aggressive unsupporting of 6.x, we loosened it to being able to mark as supported, and defaulting everything to unsupported.

That probably explains it.

Seems like defaulting everything to unsupported is not what we want, based on the above testing. (It kind of makes setting the supported branch to "999999" a no-op for those projects.)

Perhaps it should be a new issue - the status change was a cross-post too.

Is there a notice somewhere on drupal.org that outlines how the available updates page now works for Drupal 6?
It would be nice to know for sure to plan a sensible approach for doing D6 module updates.

I find that I now have to manually check the releases list for each project because the available updates report says unsupported, even though there are bug fix releases newer than my versions.
It also says unsupported if a module has a recommended D6 release on the project page.

I notice that security updates are mentioned on the available updates report though.

Linking to an issue that I think could serve as the followup discussed above, or at least close enough.

(It retrospect maybe it shouldn't have been a separate followup issue... since it seems like the end result here was that the fix implemented here only really wound up happening for a tiny number of modules in practice.)

The end result is terrible: People running D6 has no way of updating their contrib modules to the latest releases. And the one contrib module that helps with it is not mentioned anywhere except deep down in issue queues.

Yeah I can understand wanting to make it clear that a version is unsupported, but making life more difficult for users of the old version is not great.

If the data was available (maybe it is, I don't know) so that a contrib module could provide an accurate update status for D6 that would be good.

IMO that's no longer the responsiblity of d.o to provide. The myDropWizard provides it and also helps people learn about their LTS options. Maybe other LTS vendors also offer a similar thing?

If it's not easy enough to find that module then we could consider making it easier to find? Any specific suggestions of how to make it easier to find that?

Unfortunately, though, the (unintentional) result of this issue was that the Update Status data goes out of its way to confuse people, by displaying some available D6 contrib module security updates but not others.

That is still worth fixing (in one direction or the other), either via the issue I linked above or somewhere else.