Add minimal upgrade instructions (1.x to 2.x) to project page

Created on 6 February 2024, 5 months ago
Updated 6 March 2024, 4 months ago

Problem/Motivation

I spent a couple hours researching how 2.x does splits (due to patches, mostly). In the end, I was able to just use the "Do not patch dependents" option in all the splits and ended up with only the config_split.config_split.*.yml files getting changes.

A quick upgrade guide in the project page would have saved me a lot of time.

Proposed resolution

I suggest something like:

Quick Upgrade Guide (1.x to 2.x)

In 2.x a new mechanism for handling splits was introduced (yml "patches"); developers looking to upgrade have two options:

  • Switch to the no-patches mechanism (same as 1.x):
    1. composer update drupal/config_split
    2. drush updb -y
    3. Disable the patching mechanism on all splits: edit all splits, check "Do not patch dependents", save
    4. drush config:export -y
  • Use the patches mechanism (done automatically):
    1. composer update drupal/config_split
    2. drush updb -y
    3. drush config:export -y
    4. For any inactive split, activate it and perform the above process. Committing changes each time.

The no-patches option should result in a smaller set of changes to .yml files.

πŸ“Œ Task
Status

Fixed

Version

2.0

Component

Documentation

Created by

πŸ‡¨πŸ‡΄Colombia jedihe

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

Comments & Activities

  • Issue created by @jedihe
  • πŸ‡¨πŸ‡΄Colombia jedihe
  • πŸ‡¨πŸ‡΄Colombia jedihe
  • πŸ‡¨πŸ‡΄Colombia jedihe
  • I've experienced config problems while upgrading from 1.x to 2.x (from 8.x-1.9 to 2.0.0). The release notes of config_split lack of "migration" / "Upgrading from v1 to v2" steps.

    I'd say the module maintainers need to keep the composer dependency [module dependency] for a while, the best thing you could have done is to uninstall/disable the Drupal module and not both things at once (1. uninstall it from Drupal. 2. remove it from composer [I think it's not set in composer but in the info.yml file as a module dependency]). The config_split module should have run the configuration updates first and then uninstall the config_filter module, it did the opposite due to the `composer require` need to upgrade the module in composer.

    Probably config_split module needs to keep hook update 8001 as is and add a new hook_update (8004) to the 2.x branch where you assume the config_filter is installed and uninstall it for us, that would prevent unexpected loss of configurations.

  • Status changed to Needs review 4 months ago
  • πŸ‡¨πŸ‡­Switzerland bircher πŸ‡¨πŸ‡Ώ

    I updated the module page please check it and let me know if this would have saved you some frustration. The notice about config filter is also added the the release note. I copied it from config ignore.

    RE #5: No the whole point of a major version change is that it allows "breaking changes". So I will not be adding the dependency on config filter. You should always require all your drupal modules explicitly (and in my opinion with explicit version numbers so that you don't run into problems with update hooks changing configuration that you then forget to export, drupal modules are not like php libraries, they have an impact on the database schema so they need to be managed with much more care).
    Uninstalling Config Filter is out of scope for config split, but there is ✨ Suggest uninstalling when there is no other module depending on it. Fixed which has been part of config filter since 1.11 β†’
    I try to keep the disruption between major versions of the module minimal, so yes if you don't disable patching then a bunch of the config files will be different, but it should behave largely the same. It depends on how you use config split of how much these patches affect you.

  • πŸ‡¨πŸ‡΄Colombia jedihe

    @bircher: great! the upgrade section in the project page is very useful!

    Just one small additional suggestion: is it possible to link to the step-by-step in the issue summary above from the upgrade section in the project page? seeing specific commands/steps like the ones I wrote there is super-helpful for anybody with enough experience to just start trying those out.

  • Status changed to Fixed 4 months ago
  • πŸ‡¨πŸ‡­Switzerland bircher πŸ‡¨πŸ‡Ώ

    Thanks for checking it.

    I don't know if listing commands for updating a module belong to the project page if nothing changes from the normal workflow.
    When you update any module or drupal core you need to follow this procedure.
    To point out that this is not new I usually reference the session at Drupal dev days in Sevillie 2017. https://nuvole.org/blog/2017/mar/30/our-presentations-drupal-dev-days-se...

    The steps for updating is on page 41. I think is is also somewhere in the documentation.

  • πŸ‡¨πŸ‡΄Colombia jedihe

    Alright! thanks a lot :)

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.69.0 2024