Contrib.social

[policy, no patch] Figure out core branch testing needs for contrib modules

Open on Drupal.org →
Created on 3 March 2016, over 9 years ago
Updated 6 June 2024, about 1 year ago

Problem/Motivation

Opening this as a core issue because it's 1/3rd core release cycle, 1/3rd contrib developer experience, 1/3rd DrupalCI.

https://www.drupal.org/core/d8-bc-policy → and https://www.drupal.org/core/experimental → mean that while 8.x minor releases should not have API changes as such, they're allowed to include changes that will break contrib modules relying on @internal APIs or functionality provided by experimental modules.

This allows us to actually improve 8.x in minor releases - depending on how strictly you interpret 'API change' we'd not be able to make 90% of changes we are otherwise, however it also means that sometimes core commits will cause contrib tests to start failing or actually break the module.

From core's perspective, we want to know if a specific change has broken one or more contrib modules as quickly as possible, since in some cases where a 'theoretical API change' turns out to be something lots of people were relying on, we may want to roll a patch back or add some kind of bc layer. This doesn't need to be automatic, active module maintainers are usually pretty quick to realise and open a core issue.

From contrib's perspective there are conflicting needs:

  • Contrib patches should probably always be tested against the current stable core branch - just because the minor version has a breaking change, doesn't mean the module is broken against the stable branch. It's my understanding that at the moment patches are tested against 8.1.x, longer term I think we should only make that switch when we get to release candidate stage.
  • Equally, it would be useful for contrib branch tests to be run against all active branches of core, since that notifies maintainers (once) that a core change has introduced a test failure
  • We do not have, and also do not want, support for multiple core versions in contrib modules. Since 8.0.x goes EOL as soon as 8.1.x is released, ideally contrib maintainers should not have to think about multiple core branches too much unless they're actively tracking something in the development branch, or specifically need to make a change during release candidate (at which point no more 8.0.x patch-release compatibility is needed since it's EOL by the time the new module release goes out).

    • Proposed resolution

    Not sure, just wanted a central place to discuss this since it's come up in irc several times.

    For me I think:

    - patches should only be tested against one core branch, we should increment the core branch when it gets to release candidate or potentially beta. For now that means no change until 8.2.0-beta1 or 8.2.0-rc1 since we're already testing against 8.1.x and no point changing it back

    - branches should be tested against both the current minor and the development minor. I don't think we need to worry about 8.2.x until after 8.1.x is out, so maximum of two branches at a time at least for now. Also this only needs to be every 24 hours at most.

    Remaining tasks

    User interface changes

    API changes

    Data model changes

🌱 Plan
Status

Active

Version

11.0 🔥

Component
Other  →

Last updated about 10 hours ago

Created by

🇬🇧United Kingdom catch

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.

  • Comment about 1 year ago →
    🇳🇿New Zealand quietone

    There has been no discussion here for 8 years but there has been progress in this area.

    Drupal is now using GitLab for testing and there are issues in the GitLab templates → project on this topic. There is also a wiki page for how to use GitLab CI. One section of which explains how to test the previous and next major release and the previous and next minor release, which is the proposed resolution of the issue summary. Therefore, I think this can be closed.

  • Status changed to Closed: outdated about 1 year ago
  • Comment about 1 year ago →
    🇳🇿New Zealand quietone

    catch agrees with me that this can be closed. He also pointed out that it is 'nice that it's all possible now'. And yes, it is.

  • Comment 12 days ago →
    🇳🇿New Zealand quietone

    Changing to latest version when this was closed.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024