Problem/Motivation

Configuration provided by install profiles is owned by the site once installation is complete. As such, the site builder is expected to modify the default config and the profile can not assume that config is in a certain state (or that changes to that config are desired). However, profiles that are part of distributions have a need to modify this config after installation throughout the life of the application. The reasons for modifying config fall into two broad categories, each with their own challenges:

  1. Low level updates like fixing field config
  2. Optional updates like new features

Low level features have problems like knowing which versions of dependencies are installed and the current state of the existing config. New features suffer from the fact that site builders might not want certain updates or might want part of the update to work with their existing customizations.

Proposed resolution

Several solutions to the optional updates have been developed including:

We should build a consensus around one or a combination of those tools and get some of the more popular distributions to implement it.

Remaining tasks

The resolution to lower level updates is less clear. Work with the config system maintainers to better understand the problem and figure out a path forward.

User interface changes

Most likely a UI for managing config updates provided by distributions. Config Distro does this already.

Comments

balsama created an issue. See original summary.

kingdutch’s picture

kingdutch
he/him
Primary language English
commented
Related issues: +#3008882: Roadmap for CMI 2

Linking to CMI 2.0 initiative

mtodor’s picture

mtodor commented

We also have in Thunder custom module that handles updates (thunder_updater). It uses config_update in background.

We have moved functionality with some improvements from thunder_updater module into update_helper, you can take a look here: https://www.drupal.org/project/update_helper or at https://github.com/BurdaMagazinOrg/module-update_helper

The main idea is that we generate configuration update definition (shortened CUD), what is some kind of patch for configuration and we apply that if the configuration is in the expected state. There is drupal console command that simplify usage for developers to create updates. And in the end, every update is executed over update hook.

That approach works for us, for almost 2 years now.

bojanz’s picture

bojanz commented

We also have a custom solution in Commerce:

https://github.com/drupalcommerce/commerce/blob/8.x-2.x/src/Config/Confi...
https://github.com/drupalcommerce/commerce/blob/8.x-2.x/src/Config/Confi...

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.

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.

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.