Contrib.social

[meta] Prevent 'downgrades' from maintenance minors to older minor releases for the next major version

Open on Drupal.org →
Created on 23 July 2024, about 2 months ago
Updated 1 August 2024, about 1 month ago

Problem/Motivation

See original discussion in 📌 Handling update path divergence between 11.x and 10.x Fixed for some background and https://www.drupal.org/about/core/policies/core-release-cycles/release-p... → for an overview of the new release cycle.

As of Drupal 11, we're starting to release 'maintenance minors' on the previous major branch - the first of these will be Drupal 10.4, released after Drupal 11.0.0.

For a while, we've supported minor releases for one year. This introduces a new problem that we've never had before, and didn't fully think through when we originally decided to issue maintenance minors.

The idea of a maintenance minor is broadly twofold:
1. To enable contrib modules to maintain support for both Drupal 10 and 11 more easily. This means selected API additions can be backported from 11.1.x to 10.4.x
2. To update PHP and JavaScript dependencies, so that it's easier to keep on security- (and bug-)supported versions of those dependencies until 2026, as well as allowing us to support newer PHP versions when they come out, like PHP 8.4

Both #1 and #2 mean that for example when Drupal 10.4 is released, it is likely to be a on a newer version of CKEditor 5 than Drupal 11.0.0. It is also likely to have small API additions and bugfixes not available in 11.0.0 too.

Additionally, a module that adds support for a new API added in 10.4 - let's say an annotations to attributes conversion, or just calling a new method to avoid a deprecation, could reasonably expect to add a core dependency that is >= 10.4 without having to do >= 10.4 || >= 11.0

Proposed resolution

Now that 📌 Handling update path divergence between 11.x and 10.x Fixed is in, we could add an empty hook_update_N() to 11.1, and backport this to 10.4 to use the new equivalent updates API, and if a site updates to 10.4, then tries to update to 11.0, system_requirements() will prevent the update from going ahead when it finds the equivalent update is missing on 11.x. This would prevent a site from thinking it has done a successful update, then hittting weird issues (and potentially in the worst cases data loss or site downtime) after that, however, it would still be annoying to only be told you can't update to 11.0 when you've already updated your code base, and then have to either roll your code base back to 10.4, or keeping going to 11.1.

We should also see if we can come up with another strategy, either in code or on d.o or via the release process, to prevent this situation as much as possible.

Sub-issues

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

🌱 Plan
Status

Active

Version

11.0 🔥

Component
Other  →

Last updated about 8 hours ago

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @catch
  • Comment about 2 months ago →
    🇬🇧United Kingdom catch
  • Comment about 1 month ago →
    🇺🇸United States xjm

    Reorganizing the IS a little and surfacing the urgent child issue.

  • Comment about 1 month ago →
    🇭🇺Hungary Balu Ertl Budapest 🇪🇺
  • Comment about 1 month ago →
    🇺🇸United States drumm NY, US

    xjm → credited drumm → .

  • Comment about 1 month ago →
    🇺🇸United States xjm

    Some ideas from @Balu Ertl in #d11readiness Slack:

    • Write an article on drupal.org/blog. Include a well-drawn illustration to visually support the understanding through an example (eg. CKEditor might get newer in 10.4 than in 11.0).
    • On the release notes page of 10.4, 11.0 and 11.1 compose a paragraph of text referencing the article above.
    • Post a change record focusing mainly on the related code change (if any), referencing the above article only as a background.
    • Core’s newly implemented Announcements module should also show up a post in relation with this topic – (if that feed is different from the Drupal blog)
    • Make sure the above article is curated into the upcoming editions of the Weekly Drop newsletter
    • Tweet the article link by the TheDropIsAlwaysMoving

    @drumm also said in a meeting with some core committers and DA infra staff that we should do whatever we can to enforce this at the Composer level, and not add any special custom metadata to Drupal.org about it (i.e., ideally not branch or release configurations on d.o.)

  • Comment about 1 month ago →
    🇺🇸United States drumm NY, US

    If I understand correctly, everything is still backports and 11.1 will be released before 10.4. A forward upgrade will always be possible, but should skip the earlier minor versions.

    Ideally the Composer solver should disregard 11.0 when someone has 10.4. Maybe conflict could be added to the site’s root composer.json?

    Otherwise, a post-update warning is good. Many might be skipping 11.0 when 11.1 is available anyway. Someone who does land in this situation isn’t at a dead end.

  • Comment about 1 month ago →
    🇺🇸United States xjm

    A lot of the specific implementation issues for this will end up as 11.1/10.4. We might also want to backport things to 11.0 where necessary, but that meta will be marked fixed shortly, so tracking under the active one instead.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024