Optional updates

Created on 27 June 2018, almost 7 years ago

Updated 31 May 2025, 8 days ago

As a distribution user I want to be able to receive updates that improve or add the functionality to my site that have been provided by the distribution authors.
As a distribution user I need to be able to keep my site up-to-date with the latest security updates as soon as possible.
As a distribution user I need to keep security updates separate from feature updates.
As a distribution developer I want to ship with discrete new functionality for users without forcing this functionality on existing users.

A distribution user can visit a page to list all available optional updates that a distribution has not run.
Optional updates should be able to determine if it can be run. The distribution user might have made changes to the site that make it impossible to run. For example, an optional update should be able to depend on a view existing or a taxonomy term.
Optional updates should be able to depend on each other.
Optional updates should have a title and a description of what it is going to do
Optional updates should only be run once
Optional updates should be able to create new configuration, new content entities and update existing configuration and entities.

Should optional updates should be able to depend on each other? I think we have to do this so that optional updates can be updated with other optional updates.
What about a mandatory update to an optional update? I guess we can have a hook update which checks if has be run and does the update and we will also need to "fix" the optional update because it might not have been run.
Testing - how does a distribution developer test all possible combinations?
Rollback/Revert - should be expand configuration snapshot to support it? I don't think this should be attempted in the initial implementation since it is likely to add a lot of complexity.
How do we store which updates have been run? State vs configuration? hookupdateN and post updates are stored in state. Storing in state feels problematic because it problems with config sync because if a developer runs the optional update locally and this makes config changes do we need to run the optional update on target environment? Storing in config is problematic because not all changes will be to configuration.
Naming: I've started with optional updates due to the initial discussions but there are other options. For example, feature updates.
The initial thought is why not use a feature module but this does not really scale and mixing small features with functionality on the module screen is going to be messy.

✨ Feature request

Status

Active

Version

11.0 🔥

Component

other

Created by

🇬🇧United Kingdom alexpott 🇪🇺🌍

Live updates comments and jobs are added and updated live.

Needs product manager review
It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 8 days ago →
🇳🇿New Zealand quietone
The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.

Changing to the standard issue template → would also help other contributors.

Production build 0.71.5 2024