[policy, no patch] Remove old update hooks prior to each major version (Drupal 10 and later)

Created on 5 February 2018, over 7 years ago
Updated 15 March 2023, over 2 years ago

Problem/Motivation

For Drupal 9, we removed update functions (and related test coverage) added prior to Drupal 8.8.0 - this forces sites to update to at least 8.8.0 before they update to Drupal 9, reducing the number of variables when upgrade path bugs are reported, and encouraging people to update contrib modules prior to a Drupal 9 update too. Additionally, we tried to minimise the number of updates added to Drupal 8.9.x, and made fixing known outstanding upgrade path bugs added since 8.0.0 (of which there were several) a release blocker for Drupal 9.0.0

We need to decide what the cut-off point will be for the Drupal 9-10 transition.

Proposed resolution

1. Follow the same pattern as Drupal 8. i.e. prior to updating to new major version, you must always update to the penultimate minor release of the current minor version.

For example, 9.4.0 is released at the same time as Drupal 10.0.0, then Drupal 10 should only include updates added since 9.3.0.

This has worked pretty well - we only have one or two upgrade path bugs reported since 9.0.0's release, less than we've had for most Drupal 8 minor releases.

2. Alternatively, make the cut-off point earlier, for example 9.2.0. Given that minor release security support is one year, this would allow someone to skip from 9.2.0 to 10.0.0 if they do so very promptly, and retain security support.

This potentially saves a site doing one or two minor updates. However it introduces complexity into the major update by requiring both contributed modules and core to all be updated at the same time, increasing the overall number of update functions that need to run at once.

Remaining tasks

Decide which of the two options to go for, or other options if they come up.

User interface changes

API changes

Data model changes

Release notes snippet

Sites must upgrade to Drupal 8.8 or Drupal 8.9 prior to updating to Drupal 9.0.0

🌱 Plan
Status

Needs review

Version

10.0 ✨

Component
BaseΒ  β†’

Last updated about 11 hours ago

Created by

πŸ‡¨πŸ‡­Switzerland berdir Switzerland

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¬πŸ‡§United Kingdom catch

    Re-titling.

  • πŸ‡¬πŸ‡§United Kingdom catch

    Quoting some discussion from πŸ“Œ [policy] Remove update hooks added until 10.3 from Drupal 11 RTBC .

    GΓ‘bor Hojtsy

    Now that Drupal 10 will be supported until the Drupal 12 is released, would it not be in line with that intent to keep the update functions instead? I understand that removing the upgrade functions is standard practice, but https://www.drupal.org/blog/drupal-10-will-be-supported-until-the-releas β†’ ... would be counter to that?

    @catch:

    There are three reasons to remove older update functions:

    1. To encourage sites to update contributed modules to 11.x-compatible versions before updating core to 11.x. i.e. sites on 10.3.x with updated contrib modules are much more likely to update to 11.0.x successfully than sites on 10.0.0 trying to jump all the way to 11.x and updating their contrib modules at the same time.

    Sites on 10.0 may not be able to update contrib modules to 11.x compatible versions at all (if they rely on APIs added in 10.1 or 10.2), and they also may struggle to composer update contrib + core all the way from 10.0 to 11.0, because updating lots of composer dependencies at the same time gets very, very complicated.

    2. To minimize the number of (core and contrib) update functions that can potentially have to run in the same update, for example if a site tried to update all the way from 10.0.0 to 11.6.0 (which would represent 4-5 years of core development) there could be tens of updates that need to run, config that gets updated multiple times for different changes etc. The more updates can potentially run, the more likely it is that we end up with dependency issues where update X has to run before update Y but after update Z and similar.

    3. To reduce the matrix of update paths that we don't have test coverage for. e.g. ideally we'd have test coverage for 10.3-11.0, 10.4-11.0, 10.5-11.0, 10.3-11.1, 10.4-11.1, 10.5-11.1, 11.0-11.1 etc. but we don't have anything like that and can't add it with the current update test infrastructure.

    I think that #1 is about the same with 10-11 as it was for 9-10. But #2 and #3 will actually be worse with two active branches, since we'll have more total minor releases to juggle, more updates paths to potentially backport between major versions (or not), and more potential paths to for people to take between different combinations of versions.

    Or tl;dr, we've said that 10.x will be supported until Drupal 12.0, but we didn't say that Drupal 10.0 will be supported until 12.0.

    fwiw I discussed #7 briefly with GΓ‘bor in slack and we realised that removing updates from 10.0-10.3 from 11.x doesn't preclude updating from Drupal >= 10.3 to 12.0.

    That will depend on the functions added from 10.4/11.0 onwards and when those get removed. e.g. there could be a situation where you can update from 10.6 and 11.4 to 12.0, but not from 10.5 and 11.3. Or it could be that you can update only from 11.4+ to 12.0 - it all depends what gets backported to Drupal 10 minor releases, and what the cut-off point is. This doesn't automatically mean we'll support a Drupal 10-12 update path, but it adds an extra thing to think about in #2942096: [policy, no patch] Remove old update hooks prior to each major version (Drupal 10 and later) and is unaffected by this issue.

    What this issue will do is prevent direct updates from Drupal 9.5-10.2 to Drupal 11.

  • Status changed to RTBC over 1 year ago
  • πŸ‡¬πŸ‡§United Kingdom catch

    I've updated the issue summary with a better explanation of why this happens, the pattern we've followed for 8-9, 9-10 and 10-11, and how this might look when we have 10/11/12 branches all open at the same time.

    Since this is de-facto what we've been doing every major release, successfully, for several years now, going to go ahead and mark RTBC. We might want a new issue to track 10.x update backports from 11.x which is its own not small can of worms.

  • πŸ‡³πŸ‡ΏNew Zealand quietone

    This change can be added to https://www.drupal.org/about/core/policies/core-change-policies/continuo... β†’

    Update functions added to the minor release that coincides with the first release window of the next major version are removed. After Drupal 11, this changes so that update functions added to the minor release that coincides with the major release are removed.

    This issue has a change record, it doesn't seem to me that it is still needed?

  • πŸ‡¬πŸ‡§United Kingdom catch

    I removed this issue from the change record, the CR is still valid for the other issues it was attached to.

  • πŸ‡¬πŸ‡§United Kingdom catch
  • πŸ‡ΊπŸ‡ΈUnited States xjm

    For what it's worth, after seeing the D9 and D10 upgrade paths, I've come around to agreeing strongly with @catch's recommendation.

  • πŸ‡ΊπŸ‡ΈUnited States xjm

    I also agree with tracking upgrade path backports; tagging for a followup for that. I guess it would be a child of the D12 meta tree which may also need creation still?

  • πŸ‡ΊπŸ‡ΈUnited States xjm

    Removing the RM tag since we all agree on this.

  • πŸ‡¬πŸ‡§United Kingdom catch

    I was going to open a new issue for the 11.x and 10.x update path co-ordination, then I thought I'd better reference πŸ“Œ Handling update path divergence between 11.x and 10.x Fixed , then I realised nothing has changed. Have updated the issue summary there with the new major version numbers. Let's use that one.

  • πŸ‡¬πŸ‡§United Kingdom catch
  • πŸ‡­πŸ‡ΊHungary GΓ‘bor Hojtsy Hungary

    I see how this improved our stability and made our life less complicated. I also think its a far fetched idea that Drupal 10.x users would update to 12.x in place, that would require all of their contribs to somehow support that update too. So we don't need to bend over backwards to support that. Let's consider this policy agreed and refine the update functions if/when we have feasibly backportable solutions.

  • Status changed to Fixed about 1 year ago
  • Automatically closed - issue fixed for 2 weeks with no activity.

  • πŸ‡³πŸ‡ΏNew Zealand quietone

    Changing to latest version when this was closed.

  • πŸ‡³πŸ‡ΏNew Zealand quietone
Production build 0.71.5 2024