There are several issues in the Drupal 8 queue that rename functions, or add brand new functions that don't exist in Drupal 7.

For brand new functions, these might be API additions we'd want to add to Drupal 7 if they'll be useful.

For renamed functions it might be worth adding wrapper functions to Drupal 7 for 'forwards compatibility' - contrib modules can start using them now, and that's one less thing to change when upgrading.

The first of these we did several times in D6, for example the lock framework was completely new. We have not traditionally done the second.

So this is a two part issue really:

- what do we think is worth backporting? Is it worth adding wrapper functions to D7 or is that cruft?

- for new API functions that are added (and possibly additional arguments to existing functions), is it worth adding a backports defgroup to Drupal 7 to help those be more easily identified and track them?

Comments

joachim’s picture

- for new API functions that are added (and possibly additional arguments to existing functions), is it worth adding a backports defgroup to Drupal 7 to help those be more easily identified and track them?

It would allow module authors who make use of API function foo_new_in_7.6() to easily spot that they need to specify the core version that their module requires, which would result in fewer support requests. On that basis alone, I'd say yes.

catch’s picture

Title: Consider 'backports' defgroup for new functions added to D7 » RFC: 'backports' defgroup for new functions added to D7

That's going to be more of an issue with the new security releases as well. Say we release 7.5 as a security release, then 7.6 with a new function. If there is no further security release for 2-3 months, sites can legitimately stay on the version until the next one.

catch’s picture

Title: RFC: 'backports' defgroup for new functions added to D7 » RFC: forwards compatibility in D7 / 'backports' defgroup

Slightly widening scope of the issue, based on discussions in:

#778346: system_sort_modules_by_info_name() is misnamed

and

#1174444: Make the _element_validate_* functions in field.module available for all contrib modules to use

The main issue with doing this is that we regularly change APIs multiple times - i.e. we might rename a function twice, or completely remove it later on

Status: Active » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.