[policy] Extending code marked with @internal or @final should not prevent acceptance

Created on 21 May 2025, 12 days ago

While discussing this issue 🐛 ModerationHandler is both a base class and @internal Postponed: needs info @cmlara mentioned that extending code that uses @internal sometimes prevents user's applications for security coverage.

I'd like to discuss this policy because I think it might be a misapplication or misunderstanding of what @internal represents.

@internal only represents that the code marked is not covered by the BC policy. It does not mean that a user should not extend or use a class.

The main thing is if a class is marked @internal then breaking changes can be introduced without warning or BC and it's up to the module maintainer to update the project to meet the changes.

It's not clear to me why extending @internal would present a consideration for security coverage. It's not a bad practice to extend it and code extending it should still be covered by security policies.

📌 Task
Status

Active

Component

other

Created by

🇺🇸United States nicxvan

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

Comments & Activities

  • Issue created by @nicxvan
  • 🇺🇸United States nicxvan
  • 🇺🇸United States nicxvan
  • 🇮🇹Italy apaderno Brescia, 🇮🇹
  • 🇮🇹Italy apaderno Brescia, 🇮🇹

    It's not clear to me why extending @internal would present a consideration for security coverage.

    Applications to get the permission to opt projects into security advisory coverage verify what the person who applies understands about writing secure code that follows the Drupal coding standards and correctly uses the Drupal APIs, following the Drupal best practices. ( Apply for the permission to opt into security advisory coverage / Purpose )
    Verifying a class/method/function that is not backward compatible is not used is part of the correctly uses the Drupal APIs; that includes the internal classes/methods/functions and classes/methods/functions that are new in Drupal N that are used in modules compatible with previous Drupal releases.

  • 🇺🇸United States nicxvan

    Thank you, I think the point to discuss is that it is acceptable to extend internal code, the only thing is the module author is responibke to test with new releases because core will not provide bc and deprecations.

  • 🇮🇹Italy apaderno Brescia, 🇮🇹

    it is acceptable to extend internal code

    It depends on the code: If a class would extend an internal class just to add its own methods, when there is a base class, that would not be acceptable.
    The purpose of the applications is pointing out those cases; not pointing out them would be not reporting that a module that is compatible with Drupal 10 and Drupal 11 is using a class that exist only in Drupal 11.

  • 🇮🇹Italy apaderno Brescia, 🇮🇹
Production build 0.71.5 2024