Constructing service "validation.constraint" from a parent definition is not supported at build time [#2915332]

Solution

tl;drcomposer update "drupal/libraries"

Original reportt

When updating from 8.3.7 to 8.4.0, I recieve the following error:

Constructing service "validation.constraint" from a parent definition
is not supported at build time. in
/srv/bindings/***/code/vendor/symfony/dependency-injection/ContainerBuilder.php:847
Stack trace:
#0
/srv/bindings/***/code/vendor/symfony/dependency-injection/ContainerBuilder.php(451):
Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\DefinitionDecorator),
'validation.cons...')
#1
/srv/bindings/***/code/vendor/symfony/dependency-injection/ContainerBuilder.php(957):
Symfony\Component\DependencyInjection\ContainerBuilder->get('validation.cons...',
1)
#2
/srv/bindings/***/code/vendor/symfony/dependency-injection/ContainerBuilder.php(954):
Symfony\Component\DependencyInjection\ContainerBuilder->resolveServices(Object(Symfony\Component\DependencyInjection\Reference))
#3
/srv/bindings/***/code/vendor/symfony/dependency-injection/ContainerBuilder.php(1145):
Symfony\Component\DependencyInjection\ContainerBuilder->resolveServices(Array)
#4
/srv/bindings/***/code/vendor/symfony/dependency-injection/ContainerBuilder.php(918):
Symfony\Component\DependencyInjection\ContainerBuilder->callMethod(Object(Drupal\Core\Config\TypedConfigManager),
Array)
#5
/srv/bindings/***/code/vendor/symfony/dependency-injection/ContainerBuilder.php(451):
Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition),
'config.typed')
#6
/srv/bindings/***/code/vendor/symfony/dependency-injection/ContainerBuilder.php(957):
Symfony\Component\DependencyInjection\ContainerBuilder->get('config.typed',
1)
#7
/srv/bindings/***/code/vendor/symfony/dependency-injection/ContainerBuilder.php(954):
Symfony\Component\DependencyInjection\ContainerBuilder->resolveServices(Object(Symfony\Component\DependencyInjection\Reference))
#8
/srv/bindings/***/code/vendor/symfony/dependency-injection/ContainerBuilder.php(879):
Symfony\Component\DependencyInjection\ContainerBuilder->resolveServices(Array)
#9
/srv/bindings/***/code/vendor/symfony/dependency-injection/ContainerBuilder.php(451):
Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition),
'config.factory')
#10
/srv/bindings/***/code/modules/libraries/src/LibrariesServiceProvider.php(29):
Symfony\Component\DependencyInjection\ContainerBuilder->get('config.factory')
#11
/srv/bindings/***/code/core/lib/Drupal/Core/DependencyInjection/Compiler/ModifyServiceDefinitionsPass.php(30):
Drupal\libraries\LibrariesServiceProvider->alter(Object(Drupal\Core\DependencyInjection\ContainerBuilder))
#12
/srv/bindings/***/code/vendor/symfony/dependency-injection/Compiler/Compiler.php(120):
Drupal\Core\DependencyInjection\Compiler\ModifyServiceDefinitionsPass->process(Object(Drupal\Core\DependencyInjection\ContainerBuilder))
#13
/srv/bindings/***/code/vendor/symfony/dependency-injection/ContainerBuilder.php(573):
Symfony\Component\DependencyInjection\Compiler\Compiler->compile(Object(Drupal\Core\DependencyInjection\ContainerBuilder))
#14
/srv/bindings/***/code/core/lib/Drupal/Core/DrupalKernel.php(1307):
Symfony\Component\DependencyInjection\ContainerBuilder->compile()
#15
/srv/bindings/***/code/core/lib/Drupal/Core/DrupalKernel.php(884):
Drupal\Core\DrupalKernel->compileContainer()
#16
/srv/bindings/***/code/core/lib/Drupal/Core/DrupalKernel.php(466):
Drupal\Core\DrupalKernel->initializeContainer()
#17
/srv/bindings/***/code/core/lib/Drupal/Core/DrupalKernel.php(709):
Drupal\Core\DrupalKernel->boot()
#18
/srv/bindings/***/code/core/includes/utility.inc(43):
Drupal\Core\DrupalKernel->prepareLegacyRequest(Object(Symfony\Component\HttpFoundation\Request))
#19 /opt/pantheon/drush8/commands/core/cache.drush.inc(302):
drupal_rebuild(Object(Composer\Autoload\ClassLoader),
Object(Symfony\Component\HttpFoundation\Request))
#20 /opt/pantheon/drush8/includes/command.inc(422):
drush_cache_rebuild()
#21 /opt/pantheon/drush8/includes/command.inc(231):
_drush_invoke_hooks(Array, Array)
#22 /opt/pantheon/drush8/includes/command.inc(199): drush_command()
#23 /opt/pantheon/drush8/lib/Drush/Boot/BaseBoot.php(67):
drush_dispatch(Array)
#24 /opt/pantheon/drush8/includes/preflight.inc(66):
Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#25 /opt/pantheon/drush8/drush.php(12): drush_main()
#26 {main} [0.38 sec, 15.68 MB]

Someone posted something similar on StackExchange. I posted my input here.

When I downloaded the Drupal 8.4.0 zip from the Drupal Github mirror repo, unzipped, then grepped through the code, I found this:

$ grep -rF 'validation.constrain'
drupal-8.4.0/core/core.services.yml:      - [setValidationConstraintManager, ['@validation.constraint']]
drupal-8.4.0/core/core.services.yml:      - [setValidationConstraintManager, ['@validation.constraint']]
drupal-8.4.0/core/core.services.yml:  validation.constraint:
drupal-8.4.0/core/lib/Drupal/Core/Validation/Plugin/Validation/Constraint/ComplexDataConstraint.php:    $constraint_manager = \Drupal::service('validation.constraint');

Is it possible that Symfony deprecated this validation.constraint configuration key, and yet Drupal forgot to make the necessary change in their 8.4.0 code?

Comment	File	Size	Author
#18	2915332-18.patch	9.06 KB	dawehner
#18	8.4.x: PHP 7 & MySQL 5.5 22,282 pass

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

11 October 2017 at 00:25

xeM8VfDh created an issue. See original summary.

Comment #2

xeM8VfDh CreditAttribution: xeM8VfDh commented 11 October 2017 at 00:27

Issue summary:

View changes

Comment #3

cilefen CreditAttribution: cilefen as a volunteer commented 11 October 2017 at 00:41

Issue tags:

+8.4.0 update

Comment #4

xeM8VfDh CreditAttribution: xeM8VfDh commented 11 October 2017 at 21:38

Environment

my site is running on Pantheon with PHP 7.0.

Background

I initiated the site update via Pantheon's interface, which I believe is running Drush on the back end to handle this operation. Sorry I don't have more detailed steps to produce the problem, but the StackExchange links i posted does report the problem resulting from drush updb. But, that's not realy an important detail to focus on. Once I ran into this issue after trying to update, any/all drush commands (including cache clearing) result in the same error. The problem is that the application is unable to bootstrap itself and spin up, thus it cannot fullfill any requests (web, Drush, or otherwise). As far as I can tell, the system is failing to spin up because it is choking on the core Drupal configuration in core/core.services.yml that I referenced at the end of my issue.

When the Kernel is booting, it is instantiating the config.typed configuration, which in turn calls the validation.constraint which is configured with a parent attribute, making it a configuration instance of DefinitionDecorator instead of Definition. The createService() method on ContainerBuilder is choking right off the bat with:

if ($definition instanceof DefinitionDecorator) {
    throw new RuntimeException(sprintf('Constructing service "%s" from a parent definition is not supported at build time.', $id));
}

As the message suggests: Constructing a service from a parent definition is not supported at build time.

The problem was introduced in this commit when @validation.constraint became a dependency of config.typed via the calls attribute added in the commit:

config.typed:
    class: Drupal\Core\Config\TypedConfigManager
    arguments: ['@config.storage', '@config.storage.schema', '@cache.discovery', '@module_handler', '@class_resolver']
    tags:
      - { name: plugin_manager_cache_clear }
    calls:
      - [setValidationConstraintManager, ['@validation.constraint']]

Workaround

Edit core/core.services.yml and comment out the calls attribute for the config.typed block as follows:

config.typed:
    class: Drupal\Core\Config\TypedConfigManager
    arguments: ['@config.storage', '@config.storage.schema', '@cache.discovery', '@module_handler', '@class_resolver']
    tags:
      - { name: plugin_manager_cache_clear }
    #calls:
    #  - [setValidationConstraintManager, ['@validation.constraint']]

Now go to [your_url]/update.php in a browser. There will be pending database updates that need to run. That's it.

WARNING

I have no idea what the repercussions of the configuration change above are. I don't suggest anyone do this in production. It's just a demonstration of what is causing the problem and how to hack around it. As far as I can tell, this is a Drupal bug stemming from an improper usage of the new Symfony configuration standard. I have no idea why/how this wasn't caught in QA before 8.4.0 was released, but I am guessing it is because only a certain set of circumstances cause the bootstrap process to instantiate config.typed, otherwise everyone who updated to 8.4.0 would be experiencing this problem, and no QA would have passed because all 8.4.0 instances would be choking in this way. I will look into what circumstances in my environment trigger config.typed and report back if I find anything.

Comment #5

xeM8VfDh CreditAttribution: xeM8VfDh commented 11 October 2017 at 22:19

Comment #6

xeM8VfDh CreditAttribution: xeM8VfDh commented 11 October 2017 at 23:17

My testing indicated that my boot strapping process is instantiating configured serviced in this order:

config.factory
config.typed
validation.constraint

Some further inspection of the stack trace suggests that config.factory is being instantiated in code/modules/libraries/src/LibrariesServiceProvider.php. That's coming from the Libraries module. There is a working but not "official" Drupal 8 release. I have it installed because I am using Juicebox module, which requires it.

I've tested putting the original core/core.services.yml file back in place, disabling Juicebox, disabling Libraries, then executing a drush cache clear, and the problem no longer occurs. So, this update problem doesn't affect all systems but does affect those with Libraries module installed.

The question now is, is this really the fault of Libraries module, or is there still an inherent problem with the new config.typed configurations use of validation.constraint in its new calls attribute?

How to Reproduce This Error

If you are on a version below 3.4.0:

install Libraries module
initiate update to 3.4.0 using Drush or whatever method you choose

If you are already on version 3.4.0:

install Libraries module

Comment #7

mhavelant CreditAttribution: mhavelant at Brainsum for Tieto commented 12 October 2017 at 13:06

I get the same error. I have a site with core 8.3.7, and wanted to update it to 8.4.0.

My site is based on the drupal-composer project.
I don't have the libraries module installed.
I'm running it with docker, PHP7
It's a standard profile installation

The error was there when I first used drush updb on 8.4, and didn't go away after upgrading to drush 9 (as the answer from stackexchange suggested).

Comment #8

emdahlstrom CreditAttribution: emdahlstrom commented 12 October 2017 at 12:33

Disabling libraries api worked for me too, many thanks!

Comment #9

xeM8VfDh CreditAttribution: xeM8VfDh commented 12 October 2017 at 16:59

As it turns out, in my case, this might only have been a problem with Libraries release 8.x-3.x-dev (2016-Nov-13) that I was running, not the current 8.x-3.x-dev release. Digging more into it now.

Comment #10

xjm

she/her

English

CreditAttribution: xjm at Acquia commented 12 October 2017 at 18:12

@mhavelant, what happens if you run update.php through the user interface?

Comment #11

xeM8VfDh CreditAttribution: xeM8VfDh commented 12 October 2017 at 18:32

My Solution

restore backup
update Libraries Module from 8.x-3.x-dev (2016-Nov-13) to latest 8.x-3.x-dev
Get Pantheon support to restart my webstie container to get around Fatal Error cause by step above (more)
run update.php for good measure
update core to 8.4.0

Still not sure though whether Drupal core devs intentionally wanted to make config.typed inaccessible at build time. If the answer is yes, feel free to close this.

@mhavelant , if you post your stack trace, we can probably identify the module that is causing this in your case.

Comment #12

fgm

French

Paris, France

CreditAttribution: fgm at OSInet commented 13 October 2017 at 15:05

FWIW, I encounter the same (apparently rare) error in a different context in code I'm writing, when trying to obtain the config.factory in a CompilerPass.

Comment #13

larowlan

🇦🇺🏝.au GMT+10

CreditAttribution: larowlan at PreviousNext commented 20 October 2017 at 01:12

Issue summary:

View changes

Updating libraries API was the fix for me too

I think we can mark that in the OP and call this resolved?

Comment #14

mhavelant CreditAttribution: mhavelant at Brainsum for Tieto commented 20 October 2017 at 10:54

I tried to update another 8.3.7 site with the same error message.

@xjm Update.php throws the same exception.
@xeM8VfDh The stack trace:

[20-Oct-2017 10:48:23 UTC] Symfony\Component\DependencyInjection\Exception\RuntimeException: Constructing service "validation.constraint" from a parent definition is not supported at build time. in /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php on line 844 #0 /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php(451): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\DefinitionDecorator), 'validation.cons...')
#1 /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php(954): Symfony\Component\DependencyInjection\ContainerBuilder->get('validation.cons...', 1)
#2 /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php(951): Symfony\Component\DependencyInjection\ContainerBuilder->resolveServices(Object(Symfony\Component\DependencyInjection\Reference))
#3 /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php(1142): Symfony\Component\DependencyInjection\ContainerBuilder->resolveServices(Array)
#4 /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php(915): Symfony\Component\DependencyInjection\ContainerBuilder->callMethod(Object(Drupal\Core\Config\TypedConfigManager), Array)
#5 /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php(451): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition), 'config.typed')
#6 /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php(954): Symfony\Component\DependencyInjection\ContainerBuilder->get('config.typed', 1)
#7 /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php(951): Symfony\Component\DependencyInjection\ContainerBuilder->resolveServices(Object(Symfony\Component\DependencyInjection\Reference))
#8 /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php(876): Symfony\Component\DependencyInjection\ContainerBuilder->resolveServices(Array)
#9 /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php(451): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition), 'config.factory')
#10 /var/www/html/web/modules/contrib/cors_ui/src/CorsUiCompilerPass.php(22): Symfony\Component\DependencyInjection\ContainerBuilder->get('config.factory')
#11 /var/www/html/vendor/symfony/dependency-injection/Compiler/Compiler.php(120): Drupal\cors_ui\CorsUiCompilerPass->process(Object(Drupal\Core\DependencyInjection\ContainerBuilder))
#12 /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php(573): Symfony\Component\DependencyInjection\Compiler\Compiler->compile(Object(Drupal\Core\DependencyInjection\ContainerBuilder))
#13 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(1307): Symfony\Component\DependencyInjection\ContainerBuilder->compile()
#14 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(884): Drupal\Core\DrupalKernel->compileContainer()
#15 /var/www/html/vendor/drush/drush/lib/Drush/Drupal/DrupalKernel.php(61): Drupal\Core\DrupalKernel->initializeContainer()
#16 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(466): Drush\Drupal\DrupalKernel->initializeContainer()
#17 /var/www/html/vendor/drush/drush/lib/Drush/Boot/DrupalBoot8.php(146): Drupal\Core\DrupalKernel->boot()
#18 /var/www/html/vendor/drush/drush/includes/bootstrap.inc(354): Drush\Boot\DrupalBoot8->bootstrap_drupal_full()
#19 /var/www/html/vendor/drush/drush/includes/bootstrap.inc(509): drush_bootstrap(5, 7)
#20 /var/www/html/vendor/drush/drush/includes/bootstrap.inc(456): drush_bootstrap_max()
#21 /var/www/html/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(59): drush_bootstrap_to_phase(-2)
#22 /var/www/html/vendor/drush/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#23 /var/www/html/vendor/drush/drush/drush.php(12): drush_main()
#24 {main}
Drush command terminated abnormally due to an unrecoverable error.                                                                [error]
Symfony\Component\DependencyInjection\Exception\RuntimeException: Constructing service "validation.constraint" from a parent definition is not supported at build time. in Symfony\Component\DependencyInjection\ContainerBuilder->createService() (line 844 of /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php).

This site doesn't have 'Libraries' either, but it's based off the minimal profile unlike the other one. The other major points are the same (drupal-composer project, php7, trying to update from 8.3.7).

Comment #15

fgm

French

Paris, France

CreditAttribution: fgm at OSInet commented 24 October 2017 at 09:54

Dug a bit further on this: it happens because the config.factory needs to receive the config.typed, which is where this attempt at adding a validation.constraint takes place.

Comment #16

dawehner

German

CreditAttribution: dawehner at Chapter Three commented 20 October 2017 at 15:28

One way around that could be to make validation.constraint a lazy service. Config validation should not be triggered on container build time.

Comment #17

Alan D. CreditAttribution: Alan D. commented 21 October 2017 at 08:35

Also hit this with both a composer update and separately with a manual update last week. The cause was the libraries module, and placing the latest dev version post-update didn't help.

I didn't try updating the libraries module before doing core update that comment #11 suggested as a workaround, the module wasn't used so I just nuked it.

So Libraries & Cors UI (comment #14) problematic.

#10 /var/www/html/web/modules/contrib/cors_ui/src/CorsUiCompilerPass.php(22): Symfony\Component\DependencyInjection\ContainerBuilder->get('config.factory')

Comment #18

dawehner

German

CreditAttribution: dawehner at Chapter Three commented 21 October 2017 at 15:30

Status:

Active

» Needs review

File	Size
2915332-18.patch	9.06 KB
8.4.x: PHP 7 & MySQL 5.5 22,282 pass

Does this solve the problem?

Comment #19

fgm

French

Paris, France

CreditAttribution: fgm at OSInet commented 22 October 2017 at 09:07

I'm a bit skeptical on this patch, even if it solves the problem: since most - if not all - pages use the config factory, it seems this solution only adds a bit more work on all pages, does it not ?

Comment #20

dawehner

German

CreditAttribution: dawehner at Chapter Three commented 22 October 2017 at 17:46

@fgm
The config validation is just used during saving, so I think its fine?

Comment #21

fgm

French

Paris, France

CreditAttribution: fgm at OSInet commented 22 October 2017 at 20:09

@dawehner : it may well be that I misunderstand what's going on, but AIUI with this patch, the new proxy class is used any time a reference to the config factory is done, to defer instantiation until a method is actually used on the service, at which point the lazyLoadItself() calls the original (now proxied) service, meaning all (most) pages now incur one more autoload and function call, meaning a tiny bit of performance lost.

Admittedly, it is not used on pages served by the internal page cache, where it would be more significant, so maybe it is not really an issue.

Comment #22

dawehner

German

CreditAttribution: dawehner at Chapter Three commented 23 October 2017 at 04:10

Admittedly, it is not used on pages served by the internal page cache, where it would be more significant, so maybe it is not really an issue.

Its not only that, it is also not used on uncached requests as well. These methods should just be used on POST requests technically.

Comment #23

xeM8VfDh CreditAttribution: xeM8VfDh commented 23 October 2017 at 23:41

@mhavelant, as @Alan D. mentioned, your specific problem stemming from the CORS UI (cors_ui) module you have installed. See #10 from your stack trace:

#10 /var/www/html/web/modules/contrib/cors_ui/src/CorsUiCompilerPass.php(22): Symfony\Component\DependencyInjection\ContainerBuilder->get('config.factory')

That module is calling the config.factory configuration, which is eventually calling config.typed, which is the source of this problem.

If you disable that module and then try updating, it might work. If you need that module, you first want to check to make sure you are on the most current version of that module. If you are, then you will want to open an issue on the module letting them know that their code is not compatible with Drupal core 8.4.0. You can reference this issue as well as others I have referenced above.

Comment #24

dawehner

German

CreditAttribution: dawehner at Chapter Three commented 23 October 2017 at 23:54

It would be super nice to have someone trying out the patch on a real site.

Comment #25

mhavelant CreditAttribution: mhavelant at Brainsum for Tieto commented 25 October 2017 at 12:51

@xeM8VfDh Disabling the cors_ui module was the key for me, I could now update 8.3.7 to 8.4, thanks!

Comment #26

ivavictoria

she/her

CreditAttribution: ivavictoria commented 31 October 2017 at 16:54

Ran into this same error; the cors_ui module is the culprit for me as well.

I gave @dawehner's patch a try, and it looks like it works. If I update to 8.4 and apply the patch, I'm able to run `drush updb` and carry on like normal.

Since I don't know the full implications of using the patch, I'm going to stick with disabling the cors_ui module for now.
I'll be keep my eye on this thread for further developments.

Comment #27

darrenwh CreditAttribution: darrenwh as a volunteer and commented 25 January 2018 at 08:27

I've recently update a site to 8.4.4 and got the above error, I applied the patch and an error issue still exists:

Error: Declaration of Drush\Command\DrushInputAdapter::hasParameterOption($values) must be compatible with Symfony\Component\Console\Input\InputInterface::hasParameterOption($values, $onlyParams = false) in
/usr/local/bin/drush-8/vendor/drush/drush/lib/Drush/Command/DrushInputAdapter.php, line 27

Comment #28

xeM8VfDh CreditAttribution: xeM8VfDh commented 25 January 2018 at 20:20

@darrenwh, is there any more to the error? If not, is there a specific reason you think your issue relates to this issue/patch? Your error seem more related to these other issues:

https://www.drupal.org/project/drupal/issues/2890294
https://www.drupal.org/project/drupal/issues/2874827

Comment #29

darrenwh CreditAttribution: darrenwh as a volunteer and commented 25 April 2018 at 19:06

Having read this https://drupal.stackexchange.com/questions/247703/what-is-the-cause-for-...

I update libraries to latest version that seems to have resolved the issue

composer require 'drupal/libraries:^3.0'

Comment #30

25 April 2018 at 19:06

Version:

8.4.0

» 8.4.x-dev

Core issues are now filed against the dev versions where changes will be made. Document the specific release you are using in your issue comment. More information about choosing a version.

Comment #31

25 April 2018 at 19:06

Version:

8.4.x-dev

» 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Branches prior to 8.8.x are not supported, and Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should 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.

Comment #32

25 April 2018 at 19:06

Version:

8.9.x-dev

» 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Comment #33

25 April 2018 at 19:06

Version:

9.2.x-dev

» 9.3.x-dev

Comment #34

25 April 2018 at 19:06

Version:

9.3.x-dev

» 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should 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.