Problem/Motivation

In #2929496: Add dedicated interfaces to group methods dealing with revision translation and clean up the related documentation we cleaned up the interfaces providing revision and translation support to the Entity system. However, to complete the clean-up an API change would be needed: changing TranslatableStorageInterface::createTranslation() to accept a \Drupal\Core\Entity\TranslatableInterface parameter instead of a ContentEntityInterface parameter. However this is technically a BC break.

Proposed resolution

Perform this change anyway, as it may be considered an acceptable change in broad terms because:

  • TranslatableStorageInterface is not an @api interface and it has an implementing base class;
  • no existing code will actually break, aside from implementers not extending the base class, which is consistent with method additions, or overriding the method (unlikely);
  • API consuming code should keep working in the future, as ::createTranslation() is a quasi-internal method that almost no one will actually need to use directly;
  • implementers just need to keep returning an instance of the same class of the $entity parameter for everything to work smoothly.

Remaining tasks

  • Write a patch
  • Perform reviews
  • Obtain release manager signoff

User interface changes

None

API changes

public function createTranslation(ContentEntityInterface $entity, $langcode, array $values = []); // Before
public function createTranslation(TranslatableInterface $entity, $langcode, array $values = []); // After

Data model changes

None

Comments

plach created an issue. See original summary.

plach’s picture

Here's the patch.

plach’s picture

Issue summary: View changes
plach’s picture

StatusFileSize
new3.38 KB

Let's try again

plach’s picture

Title: [PP-1] Change TranslatableStorageInterface::createTranslation() to accept TranslatableInterface » Change TranslatableStorageInterface::createTranslation() to accept TranslatableInterface
Status: Postponed » Needs review

Status: Needs review » Needs work

The last submitted patch, 4: entity-create_translation_api-2932049-4.patch, failed testing. View results

plach’s picture

Status: Needs work » Needs review
plach’s picture

Status: Needs review » Reviewed & tested by the community

This change was already RTBC'ed in the parent issue, however @catch wanted to discuss with @xjm about it.

plach’s picture

Issue summary: View changes
plach’s picture

Issue summary: View changes

Updated IS

plach’s picture

Issue summary: View changes
larowlan’s picture

Assigned: Unassigned » xjm

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 4: entity-create_translation_api-2932049-4.patch, failed testing. View results

plach’s picture

Status: Needs work » Reviewed & tested by the community

Bot fluke

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 4: entity-create_translation_api-2932049-4.patch, failed testing. View results

plach’s picture

Status: Needs work » Reviewed & tested by the community

Clearly testbots are -1 on this change.

xjm’s picture

What are the implications of not doing this? It really does seem like a BC break to me, and a "clean-up" is not justification for a BC break in my mind.

catch’s picture

So there's a way to do it without an API break, but it's long-winded:

- we could add a new interface/method name and deprecate the old one, however there's no better name so it would be a worse/less self-documenting method name.

- because we've deprecated the current method, in 9.x we can then copy the new method signature back, leaving the one we just added deprecated.

- Then in Drupal 10 we remove the method we deprecated in 9.x, and end up in the same situation as if this patch was committed as-is - with the same method name we have now, but a new signature, each step preserving backwards compatibility.

There are a further two options:

1. Defer the signature change to 9.x, on the basis that while it breaks the bc policy, once the change is made a module will still work with both 8.x and 9.x (in the same way modules sometimes have to make changes for compatibility with minors). I didn't think of this option until just now though.

2. Don't change the method signature at all.

plach’s picture

Status: Reviewed & tested by the community » Postponed

This is not super-urgent and right now the committer team is pretty busy with the 8.5.x lifecycle so we agreed to get back to this when things calm down.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

amateescu’s picture

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

xjm’s picture

Assigned: xjm » Unassigned
Status: Postponed » Needs work

Definitely should not have been assigned to me all these years. Also does not need to be postponed. :)

ravi.shankar’s picture

StatusFileSize
new3.51 KB

Added reroll of patch #4 on Drupal 9.4.x.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

catch’s picture

This has had release manager review, removing the tag.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.