Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Having an alpha experimental module and trying to manage 8.9.x and 9.0.x makes things unnecessarily complex.
Proposed resolution
Remove the module - we only need it to add a UI in - the patch to do that does not exist yet and can add the module.
As an alpha experimental module we don;t need an upgrade path.
Remaining tasks
User interface changes
None
API changes
The config_environment module is removed.
Data model changes
None
Release notes snippet
The alpha experimental module config_environment module is removed.
Comment | File | Size | Author |
---|---|---|---|
#23 | interdiff_21-23.txt | 1.22 KB | Neslee Canil Pinto |
#23 | 3121229-23.patch | 2.85 KB | Neslee Canil Pinto |
#21 | 3121229-21.patch | 1.32 KB | Neslee Canil Pinto |
#2 | 3121229-9.0.x-2.patch | 2.85 KB | alexpott |
#2 | 3121229-8.9.x-2.patch | 2.87 KB | alexpott |
Comments
Comment #2
alexpottComment #3
bircherWe can leave it in 9.1 but it will unlikely get to beta before then, so I am +1 for RTBC for removing it in 8.9 and 9.1.
Comment #5
alexpottThere was a random fail on the 9.0.x patch.
Comment #6
alexpottSo the module has now been removed from 8.9.x and 9.0.x but we need to fix core/composer.json.
Comment #7
xjmHuh, I had thought the Composer Initiative changes in 8.8 made this obsolete? The need to do #6 I mean.
Comment #8
xjmAlso why didn't HEAD fail if it is referencing a non-existent module?
Comment #9
xjm#2 is still valid for 9.1.x; the issue in 9.0/8.9 just needs to be hotfixed. I'd like to understand why QA passed first though, and/or file an issue for test coverage if appropriate, because IIRC this happened when 8.6.x was branched too.
Comment #10
alexpottI don't think that having this in composer.json causes anything to happen at runtime. It does impact what would happen if you do
composer require drupal/config_environment
but given we normally don't use a contrib namespace for experimental modules this doesn't have much impact. I think this task is mostly house cleaning. And yeah we can removing this from 8.1.x too as I think we shoudl only add this back in if we get the UI up and ready.Comment #13
xjmCommitted #6 to 9.0.x and 8.9.x (or rather, regenerated the same thing by removing the line from
core/composer.json
and runningcomposer update drupal/core*
, because I wasn't sure if the lock file hash had been fixed yet).I realized that I had remembered the impact of 8.8's changes the wrong way around: One more step is now required to remove a module (of updating the lockfile), rather than one less (of not having to change
core/composer.json
).Comment #15
xjmComment #16
xjmComment #17
xjmFail doesn't have anything to do with #2.
Still wondering though if there's any test that could be added (in a followup obviously) so that QA would fail if the
core/composer.json
contains non-existent (or non-core) Drupal modules.Comment #18
alexpottYep we can add a test to ensure that core/composer.json only has replace statements for core modules that exist - and also is not missing any.
Comment #19
catchIf this has been committed already, can we mark it fixed?
Comment #20
alexpottIt's still open against 9.1.x - which I'm +1 on removing there too as I think it'll result in less release manager work. If we manage to get an experimental config environment ui in then great but adding this back can be part of that patch.
Comment #21
Neslee Canil Pinto@alexpott, patch for 9.1.x.
Comment #23
Neslee Canil PintoComment #25
catchAh OK that makes sense. Yeah we can commit the revert of this once there's a viable patch for something to keep the diff smaller if we want, but makes sense to not have it when there isn't active work on a UI in progress.
Committed 9979c5f and pushed to 9.1.x. Thanks!
Missed that this was needs review instead of RTBC, but patch is identical to previous ones except the composer.lock hash.