Contrib.social

[policy, no patch] Update allowed changes to current practice for backport of Test API changes

Open on Drupal.org →
Created on 4 July 2025, 2 days ago

Problem/Motivation

Followup from 🌱 [policy, maybe patch] Clarify backport policy for testing framework changes, including new BTB tests Closed: outdated . To paraphrase from @xjm in that issue, the discussion there is outdated and from when there were two different testing APIs.

The current policy does not reflect current practice in regard to when changes to the testing API should be backported.

Steps to reproduce

Proposed resolution

Update allowed changes → policy.

Text to be added

Remaining tasks

Agree that testing API additions should be backported to the production and maintenance minor branches.
Make the doc changes

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

📌 Task
Status

Active

Version

11.0 🔥

Component

other

Created by

🇳🇿New Zealand quietone

Live updates comments and jobs are added and updated live.
  • Needs release manager review

    It is used to alert the release manager core committer(s) that an issue significantly affects the overall technical debt or release timeline of Drupal, and their signoff is needed. See the governance policy draft for more information.

  • Needs framework manager review

    It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

Sign in to follow issues

Comments & Activities

  • Issue created by @quietone
  • Comment 2 days ago →
    🇺🇸United States xjm
  • Comment 2 days ago →
    🇺🇸United States xjm
  • Comment 2 days ago →
    🇬🇧United Kingdom catch

    Generally I'm in favour of backporting the test improvements because it helps modules support multiple branches of core with no code changes.

    However that has also been hard with performance tests where the tests themselves that rely on the APIs differ between the branches - to the point where we gave up backporting some changes to 10.x

    e.g. FooTest is added in 10.3 and 11.0, FooTest diverges from the 10.x version in 11.1. FooTestBase gets a new improvement in 11.2 - now the changes to the test itself in 11.1, that can be updated to the new API in 11.2, aren't backportable to 10.3. So you end up having to make a separate backport MR with either only the test API addition, or the API addition and also refactoring the 10.x version of the test.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024