At DrupalCon Barcelona we discussed possible ways to have package_manager and automatic updates (update manager) as alpha in tagged releases of core.
Usually, alpha-stability experimental modules are removed from release branches (e.g. they stay in 11.x but would be removed from 11.1.x). However, to update a site between releases, you need.... releases to update to/from, which creates a catch-22 (sorry) situation for a module that is all about updating sites.
The solution we came up with was to prevent package_manager and update_manager from doing anything unless a dev toggle is enabled, via #1537198: Add a Production/Development toggle.
This will ensure that it can't do anything on production then, but allow it to be tested on development environments including updating from release to release.
I can't remember the details of what we came up with for messaging/interface text for this, hopefully someone else can.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !10080
Comments
Comment #2
catchChanging the release branch version to 11.1.x since 11.0.x is already out with releases to make things less confusing.
Comment #3
catchTo support #3485006: Figure out testing process for package_manager in core (from contrib) we need to have package_manager in 11.1, or release very, very early 11.2 alphas. Very early 11.2 alphas affects the entire release process, so I think we should do this issue instead.
This means not removing package_manager from the 11.1.x branch which is what we'd normally do for an alpha-stability experimental module, and instead hiding package_manger via hidden.true in package_manager.info.yml.
We also said we'd put package_manager behind a dev/prod toggle but unfortunately #1537198: Add a Production/Development toggle isn't done yet.
But.. for package_manager specifically, any arbitrary $settings key will do because it's going to be a temporary situation anyway until it's stable. So we can just do $settings['testing_package_manager'] = TRUE or whatever without worrying too much hopefully.
Then we need a hook_requirements('install') to prevent installation unless the setting is on, and a change record, and hopefully that's enough?
Comment #4
larowlanI think any arbitrary settings key is fine
Comment #7
catchOne comment on the MR but otherwise looks great.
Comment #8
quietone commentedComment #9
phenaproximaTests are failing but I like this idea and the proposed approach. So consider this a soft RTBC when tests pass.
Comment #10
catchComment #12
dwwI think I fixed the tests. Let's see what the bot thinks.
Meanwhile, crediting @quietone for the initial work, @catch for the detailed reviews + input, and myself for trying to fix the tests...
Comment #13
catchTwo very common random test failures but otherwise green. Moving to RTBC.
Comment #17
larowlanCommitted to 11.x and backported to 11.1.x
Comment #18
dwwSweet, thanks!
I just published the CR (https://www.drupal.org/node/3486019) and set the "Introduced in version" to 11.1.0-beta1. Hope that's correct. Please edit if needed.
Thanks again,
-Derek