Problem/Motivation

In #2991207: Drupal core should inform the user of the security coverage for the site's installed minor version including final 8.x LTS releases, we added a message to the site Status Report (/admin/reports/status) explaining when security coverage for the installed minor version will end. For example, if the installed version is 8.6.1, then it will be supported until 8.7.0 is released (current policy) or 8.8.0 is released (policy proposed in #2909665: [plan] Extend security support to cover the previous minor version of Drupal).

We would like to provide actual dates in this message: "September, 2019" instead of "when 8.8.0 is released", for example.

We would also like to identify the next two releases correctly. Will they both be minor releases of the current major version, or will one of them be the next major release?

Proposed resolution

Although we have a policy for future release dates, that policy may change, so we do not want to hard-code these dates. Instead, we should add these dates to the XML feed provided by https://updates.drupal.org

Each release should include information about the next two releases:

  • major version number
  • minor version number
  • release date
  • is this an LTS version
  • is the release date actual or projected

Remaining tasks

User interface changes

None.

This information will be used to update the messages on the site Status Report (/admin/reports/status), but that will be handled by related issues.

API changes

None

Data model changes

None

Comments

benjifisher created an issue. See original summary.

benjifisher’s picture

benjifisher
he/him or they/them
Primary language English
Location Boston area
commented
Issue summary: View changes
drumm’s picture

drumm
he/him
Location NY, US
commented
Related issues: +#2688479: Update update status XML for Drupal 9 and contrib semantic versioning, +#2687957: Improve Update Status messaging for End of Life in Drupal 7(and Drupal 8 and later)

At some point, we’ll need to freeze additions to update status XML, and push to make a more-modern system, #2688479: Update update status XML for Drupal 9 and contrib semantic versioning. This will save bandwidth to Drupal.org’s CDN.

While core does much more release planning, it would be best to find a way to do this for all projects. There currently are no special cases for Drupal core in the existing update status system.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented

Checking back on this since in #2688479-5: Update update status XML for Drupal 9 and contrib semantic versioning @drumm mentioned

Yes, the existing system will be in place indefinitely. It may end up being okay to keep extending.

Not sure what the latest thoughts are on this now

#2998287: Provide accurate information on the security coverage of the 8.x final minor and LTS, and recommend updating to the next major version when appropriate is now listed as requirement for #3079680: [META] Requirements for tagging Drupal 9.0.0-beta1

We could hard-code logic in core that 8.9.x is an LTS and say that it is supported until November 2021. But the big problem would be if that changed, especially if for some reason we had to drop support before Nov 2021. Then obviously we could update core but any site running an earlier version of 8.9.x would not get the updated earlier date and still think it was Nov 2021.

I think the minimum we would need would be a date on 8.9.x releases(or just 8.9.0?) that would have a support end month.

I know there is a lot that the DA has to do to prepare for Drupal 9 so one other option would be for:

  1. Core could hard-code 8.9.x as the LTS with an end date of Nov 2021
  2. Also check for a some key in the release like lts_support_end and if that is provided use that date instead.
  3. If everything continues to go as planned drupal.org would not actually have to implement the logic for lts_support_end but if for some reason this changed drupal.org would have to add this value to the releases a later time

Of course we would have to agree on the exact key and value type beforehand because once 8.9.0 was released some sites would be running this logic.

I am not sure if this is a good idea or not but if we really think Nov 2021 is pretty certain then we could save work on Drupal.org but still have a way to react if this changes.

Of course core would need good test coverage around the security message based on lts_support_end being set.

drumm’s picture

drumm
he/him
Location NY, US
commented

With #3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates hopefully landing soon, update status now can have more of a concept of a “branch.” We will have releases in the LTS series, not LTS releases. The API could provide data like branch/lts_support_end, as in 8.9.x/2021-11, with some XML wrapping of course.

Should this really be a plain text, or simple HTML, message? At the end of D6’s lifetime, we found we really wanted to communicate what the options were for site owners, and there were scarce options. See #2687957: Improve Update Status messaging for End of Life in Drupal 7(and Drupal 8 and later)

benjifisher’s picture

benjifisher
he/him or they/them
Primary language English
Location Boston area
commented

In #2991207-165: Drupal core should inform the user of the security coverage for the site's installed minor version including final 8.x LTS releases and following comments, we discussed making the following changes as part of this issue. It is not clear to me that this is in scope, but as the one who wrote the original description of this issue, I encourage anyone who thinks this should be in scope to update the description.

Remove the following constants from the Drupal\update\ProjectSecurityData class:

  • CORE_MINORS_SUPPORTED
  • SUPPORT_END_DATE_8_8
  • SUPPORT_ENDING_WARN_DATE_8_8
  • SUPPORT_END_DATE_8_9

As noted in #169.6 of that issue, these constants are referenced in the lines

    if (defined("self::SUPPORT_END_DATE_$version_suffix")) {
      $info['support_end_date'] = constant("self::SUPPORT_END_DATE_$version_suffix");
      $info['support_ending_warn_date'] = defined("self::SUPPORT_ENDING_WARN_DATE_$version_suffix") ? constant("self::SUPPORT_ENDING_WARN_DATE_$version_suffix") : NULL;
    }

We also have #3107378: Deprecate hard-coded Drupal 8 dates from update logic for the status report once this information is provided by the infrastructure, which will remove all but the first of these constants from the 9.0.x branch.

xjm’s picture

xjm
she/her
Primary language English
commented
Issue tags: +Automatic Updates Initiative
xjm’s picture

xjm
she/her
Primary language English
commented

#3107378: Deprecate hard-coded Drupal 8 dates from update logic for the status report once this information is provided by the infrastructure is postponed on this issue.

xjm’s picture

xjm
she/her
Primary language English
commented
Related issues: +#3272956: Hardcode security coverage EOL dates for Drupal 9.4 and 9.5 (as was done for 8.8 and 8.9)

Meanwhile we'll need to go the hacky route for D9 as well.