Move some of the bootstrap.inc PHP-related constants to \Drupal and deprecate the old versions

ThemeHandlerTest is already wrong, unfortunately:

if (!defined('DRUPAL_MINIMUM_PHP')) {
  define('DRUPAL_MINIMUM_PHP', '5.3.10');
}

So yeah, we need a solution for this.

Should we just add it to \Drupal where VERSION lives for now?

Could we call it Requirements or something? Not Php. :P

I like this, and I like not having this in the `\Drupal` class. I also like the name Requirements, as it may provide a nice home for future needs.

+++ b/core/lib/Drupal/Core/Requirements.php
@@ -0,0 +1,31 @@
+  const DRUPAL_MINIMUM_PHP = '5.5.9';

Since this is already in the `Drupal\Core`, do we need the 'DRUPAL_' prefix on these constants? Or do we want to keep this as they are one-to-one mappings? I think the former would be better.

We are deprecating something, so we need a CR. I stubbed out https://www.drupal.org/node/2909361 so we have something to reference and will write it up later.

NW, for needing to write the CR and needing to reference the CR in the deprecations.

First pass at CR. Added @see CR to the docblocks.

1. +++ b/core/lib/Drupal/Core/Requirements.php
   @@ -0,0 +1,31 @@
   +  const DRUPAL_MINIMUM_PHP = '5.5.9';
   ...
   +  const DRUPAL_MINIMUM_PHP_MEMORY_LIMIT = '64M';
   

   Since we now have a namespaced class, I think we can remove DRUPAL_ from the beginning.

2. +++ b/core/lib/Drupal/Core/Requirements.php
   @@ -0,0 +1,31 @@
   +  /**
   +   * Regular expression to match PHP function names.
   +   *
   +   * @see http://php.net/manual/language.functions.php
   +   */
   +  const DRUPAL_PHP_FUNCTION_PATTERN = '[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*';
   

   I'm not sure this one belongs here; actually I'm not sure it belongs anywhere. It's only used in two places: by update.module, to look for .info.yml files, and install.inc, to detect... a database driver, of all things.

   So I'd suggest removing this one from the patch and filing a separate issue to deprecate and get rid of it entirely. It has two usages that are not even really conceptually related. Seems like a legacy thing.

Thanks @Mile23 and @mpdonadio!

#8 done, updating CR shortly.

This looks good to me. One question occurred to me:

+++ b/core/includes/bootstrap.inc
@@ -19,8 +20,13 @@
-const DRUPAL_MINIMUM_PHP = '5.5.9';
+const DRUPAL_MINIMUM_PHP = Requirements::MINIMUM_PHP;

I wondered, is there any risk of these constants being needed at a point when the autoloader isn't available? That prompted me to look at things in the early installer before the autoloader is initialized, and there's a spot in install.php that hardcodes the version to avoid fatal errors. So we're okay on that front (at least in terms of the very early installer). We can discuss what to do about that separately I think.

The constant isn't used anywhere else that seemed like a risk.

Made #2910070: Figure out better solution for PHP version check in install.php.

+++ b/core/lib/Drupal/Core/Requirements.php
@@ -0,0 +1,24 @@
+class Requirements {

Most of time constants are defined in interfaces.. is there a reason to make in in class?

+++ b/core/tests/Drupal/Tests/Core/Extension/ThemeHandlerTest.php
@@ -361,13 +361,3 @@ protected function systemListReset() {
-if (!defined('DRUPAL_EXTENSION_NAME_MAX_LENGTH')) {
...
-if (!defined('DRUPAL_PHP_FUNCTION_PATTERN')) {

This removal looks unrelated

Re-roll.

Missed Requirements class.

In respect to #14:
1) For me it feels strange to have that constants in the interface that not meant to be implemented.
2) Yes and no. Such a clean up is always a good thing for me, so I will leave a decision to someone else.

+++ b/core/tests/Drupal/Tests/Core/Extension/ThemeHandlerTest.php
@@ -361,13 +361,3 @@ protected function systemListReset() {
-
-if (!defined('DRUPAL_EXTENSION_NAME_MAX_LENGTH')) {
-  define('DRUPAL_EXTENSION_NAME_MAX_LENGTH', 50);
-}
-if (!defined('DRUPAL_PHP_FUNCTION_PATTERN')) {
-  define('DRUPAL_PHP_FUNCTION_PATTERN', '[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*');
-}
-if (!defined('DRUPAL_MINIMUM_PHP')) {

I am a bit confused why one can remove those here as well, but we don't deprecate them

The development branch is now 8.6.x

so we need to upgrade our comments of the form.

@deprecated in Drupal 8.5.0

Hi All,

I was checking the issue reported and moving all the expected const to Requirements:: to prevent duplicate const declarations. Hope it works!

Patch udated to prevent remove variables and adding @deprecated

Fix patch name

Can we get an interdiff? Not sure why this patch jumped from 3k to 10k.

Updated patch to allow install.php file access to the Requirements class + interdiff

1. Typo, as renamed without DRUPAL_

+ *   \Drupal\Core\Requirements::DRUPAL_MINIMUM_PHP_MEMORY_LIMIT instead.

+ *   \Drupal\Core\Requirements::DRUPAL_MINIMUM_PHP instead.

2. +// The minimum version is specified in the Drupal\Core\Requirements interface
we have class, not an interface

3. PHP_VERSION vs phpversion()
probably it is out of the scope of the issue, but is there any sense of using different ways of getting actual PHP version?

4. Not sure, but wouldn't it be better to add PHP version validation function to the Requirements class to be more DRY?

5. As we introduced Requirements.php, don't be better to move code from core/lib/Drupal/Component/Utility/Environment.php to it and deprecate Environment.php or extend Environment.php with version validation?

6. Probably it is out of the scope as well, but it looks like constants REQUIREMENT_ERROR, etc should be moved to Requirements class

Re #31-3-6, I think we can explore those ideas in the future but the scope of this issue is really just to move those constants onto a class (or interface, but IMHO an interface w/o a class is a bad idea) to solve the problem of needing them when unit testing, which will help some of the composer related issues and will pop up once we drop 5.5 and 5.6.

As a side note, PHP_VERSION vs phpversion(), the function is better as it can be mocked or shadowed for testing purposes.

Fixing comments 1 and 2 in #31

Needs reroll after https://www.drupal.org/node/2709919

+++ b/core/includes/install.inc
+++ b/core/includes/install.inc
@@ -1081,7 +1081,7 @@

@@ -1081,7 +1081,7 @@
       'description' => '',
       'version' => NULL,
       'hidden' => FALSE,
-      'php' => Requirements::MINIMUM_PHP,
+      'php' => DRUPAL_MINIMUM_PHP,
     ];
     $profile_file = drupal_get_path('profile', $profile) . "/$profile.info.yml";
     $info = \Drupal::service('info_parser')->parse($profile_file);
@@ -1090,7 +1090,7 @@

@@ -1090,7 +1090,7 @@
       'description' => '',
       'version' => NULL,
       'hidden' => FALSE,
-      'php' => DRUPAL_MINIMUM_PHP,
+      'php' => Requirements::MINIMUM_PHP,
     ];
     $profile_file = drupal_get_path('profile', $profile) . "/$profile.info.yml";
...
--- b/core/modules/system/system.module

--- b/core/modules/system/system.module
+++ a/core/modules/system/system.module

+++ a/core/modules/system/system.module
+++ a/core/modules/system/system.module
@@ -10,7 +10,6 @@

@@ -10,7 +10,6 @@
 use Drupal\Core\Asset\AttachedAssetsInterface;
 use Drupal\Core\Cache\Cache;
 use Drupal\Core\Queue\QueueGarbageCollectionInterface;
-use Drupal\Core\Requirements;
 use Drupal\Core\Database\Query\AlterableInterface;
 use Drupal\Core\Extension\Extension;
 use Drupal\Core\Extension\ExtensionDiscovery;
@@ -1034,7 +1033,7 @@

@@ -1034,7 +1033,7 @@
     'description' => '',
     'package' => 'Other',
     'version' => NULL,
+    'php' => DRUPAL_MINIMUM_PHP,
-    'php' => Requirements::MINIMUM_PHP,
   ];

Is there a reason to revert some of these changes ... ?

Needs work based upon #37

Google reports consts in interfaces is a bad practice for php & java

So I think this class should be final at least

Cleanup

#42 looks solid.

Reroll. Fixing one little thing shortly.

This moves the recommended version to the new class, and also removes a hardcoded value in a test.

Did a search for the issue number, and I think we caught all of the @todos, and did some usage reports in PhpStorm, and think we have caught all of the uses in core.

both places use files from current "core" dir

+++ b/core/install.php
@@ -21,11 +22,10 @@
 
-// Exit early if running an incompatible PHP version to avoid fatal errors.
-// The minimum version is specified explicitly, as DRUPAL_MINIMUM_PHP is not
-// yet available. It is defined in bootstrap.inc, but it is not possible to
-// load that file yet as it would cause a fatal error on older versions of PHP.
-if (version_compare(PHP_VERSION, '5.5.9') < 0) {
+// Checking minimum PHP version to avoid fatal errors.
+// The minimum version is specified in the Drupal\Core\Requirements class.
+require_once __DIR__ . '/lib/Drupal/Core/Requirements.php';
+if (version_compare(PHP_VERSION, Requirements::MINIMUM_PHP) < 0) {

Isn't this a problem because this now probably at least requires php 5.4 to even start executing this code?

#48, https://3v4l.org/5mS1U

Or were you thinking about `__DIR__`? That was introduced in 5.3.0, per http://php.net/manual/en/language.constants.predefined.php

Yes __DIR__ will fail early

+++ b/core/install.php
@@ -21,11 +22,10 @@
+// The minimum version is specified in the Drupal\Core\Requirements class.
+require_once __DIR__ . '/lib/Drupal/Core/Requirements.php';

@@ -40,5 +40,5 @@
-require_once $root_path . '/core/includes/install.core.inc';
+require_once __DIR__ . '/includes/install.core.inc';

The first one looks better to revert cos it will fail in PHP < 5.3 but in second one we are safe

@mpdonadio Nice research. Thank you!

1. +++ b/core/install.php
   @@ -21,11 +22,10 @@
   +require_once __DIR__ . '/lib/Drupal/Core/Requirements.php';
   +if (version_compare(PHP_VERSION, Requirements::MINIMUM_PHP) < 0) {
      print 'Your PHP installation is too old. Drupal requires at least PHP 5.5.9. See the <a href="https://www.drupal.org/requirements">system requirements</a> page for more information.';
   

   If we're making this configurable we should change the message to use the constant too.

2. +++ b/core/tests/Drupal/Tests/Core/Extension/ThemeHandlerTest.php
   @@ -368,6 +368,15 @@ protected function systemListReset() {
   +/**
   + * Minimum supported version of PHP.
   + *
   + * @deprecated in Drupal 8.6.0, will be removed before Drupal 9.0.0. Use
   + *   \Drupal\Core\Requirements::MINIMUM_PHP instead.
   + *
   + * @see https://www.drupal.org/node/2909361
   + */
   + if (!defined('DRUPAL_MINIMUM_PHP')) {
   +   define('DRUPAL_MINIMUM_PHP', '5.3.10');
   + }
   

   can this be removed? If we've replaced all the usages then the test doesn't need to fake it.

Should take care of #52.

Needs reroll

Reroll

Needs review of the patch as all of the tests passed.

Nice. Only nits:

1. +++ b/core/includes/bootstrap.inc
   @@ -22,10 +23,12 @@
   + * @deprecated in Drupal 8.6.0, will be removed before Drupal 9.0.0. Use
   
   @@ -34,10 +37,12 @@
   + * @deprecated in Drupal 8.6.0, will be removed before Drupal 9.0.0. Use
   
   @@ -46,10 +51,12 @@
   + * @deprecated in Drupal 8.6.0, will be removed before Drupal 9.0.0. Use
   

   8.6.0 => 8.7.0. The CR "Introduced in branch" field should be adapted too.

2. +++ b/core/install.php
   @@ -21,12 +22,11 @@
   +// Checking minimum PHP version to avoid fatal errors.
   +// The minimum version is specified in the Drupal\Core\Requirements class.
   

   According to Drupal API documentation standards (general):

   Lines containing comments (including docblocks) must wrap as close to 80 characters as possible without going over

   So, the beginning 2nd line ("The minimum..") should start on the 1st line.

Also... in other issue I'm trying to deprecate drupal_set_time_limit() and I'm looking for a place for a new static method that is suppose to replace the procedural function. Could we rename the new class Drupal\Core\Requirements as Drupal\Core\Php, so that we can add there such methods, that are actually setting the PHP environment?

I think better to create separate helper class like \Drupal\Component\Utility\Php for wrappers like other utility methods here

@andypost, usually, components are something that are self contained and make sens outside Drupal. Here's the other issue #3000057: Deprecate drupal_set_time_limit() and file_upload_max_size() and move to Environment component.

@Mile23, missed that :)

But now, anticipating #3000057: Deprecate drupal_set_time_limit() and file_upload_max_size() and move to Environment component, I think we can reconsider #4?

But class Requirements still needed for constants #2909480-5: Move REQUIREMENT_* constants out of install.inc file

rerolled
addressed #61

Reolled, removed other occurrence from a new tests. Interdiff is against #61.

Forgot the patch :)

Oops! Forgot to rebase on top of 8.7.x so it needed a new reroll.

1. I have removed unnecessary or unrelated changes to this issue (interdiff).
2. I changed recommended PHP version (7.1 -> 7.2) after #3034202: Recommended php version is 7.2 was fixed (re-roll).
3. All occurrences of deprecated constants (DRUPAL_MINIMUM_PHP_MEMORY_LIMIT, DRUPAL_RECOMMENDED_PHP, DRUPAL_MINIMUM_PHP) have been changed/removed.

+1 RTBC

Looks good

+++ b/core/install.php
@@ -21,12 +22,11 @@
+require_once __DIR__ . '/lib/Drupal/Core/Requirements.php';

why do we need the require_once here? is this for 'stuff is so bad the autoloader is broken'?

Looks like that. Autoloader included in a few lines below.

Rerolled.
Added deprecation for DRUPAL_MINIMUM_SUPPORTED_PHP constant.
Fixed deprecation message for DRUPAL_RECOMMENDED_PHP constant.
Moved minimal version check to autoload file.

+++ b/core/includes/bootstrap.inc
@@ -27,12 +28,13 @@
+ * @deprecated in Drupal 8.7.x, will be removed before Drupal 9.0.0. Use

Update the deprecated message.
Also, updated the CR to 8.8.0
Also, changed the usage of the DRUPAL_MINIMUM_SUPPORTED_PHP

Reroll. No interdiff "Error applying patch1 to reconstructed file"
Current minimum php version is bumped to the 7.0.8 .
Updated Requirements.php minimal version constant value and deprecation messages in bootstrap.inc to meet CS requirements.

Conflicts are just in the "use"'s sections that ware changed recently. So just reroll and fix the CS issues with deprecation messages.

There were no new usages of the constants since May...

+  /**
+   * Minimum supported version of PHP.
+   */
+  const MINIMUM_PHP = '7.0.8';

+  /**
+   * Minimum supported version of PHP.
+   *
+   * Below this version:
+   * - New sites cannot be installed, except from within tests.
+   * - Updates from previous Drupal versions can be run, but users are warned
+   *   that Drupal no longer supports that PHP version.
+   * - An error is shown in the status report that the PHP version is too old.
+   */
+  const MINIMUM_SUPPORTED_PHP = '7.0.8';

1. There are two constants with the same description "Minimum supported version of PHP." IMO MINIMUM_PHP also needs an additional description.

2. Maybe there should be one constant MINIMUM_SUPPORTED_PHP? Is there any difference?

+++ b/core/lib/autoloader.php
@@ -0,0 +1,14 @@
+// Checking minimum PHP version to avoid fatal errors.
+if (version_compare(PHP_VERSION, Requirements::MINIMUM_PHP) < 0) {
+ print 'Your PHP installation is too old. Drupal requires at least PHP ' . Requirements::MINIMUM_PHP . '. See the system requirements page for more information.';
+ exit;
+}

+++ b/core/modules/system/system.install
@@ -186,11 +187,11 @@ function system_requirements($phase) {
// Check if the PHP version is below what Drupal supports.
- if (version_compare($phpversion, DRUPAL_MINIMUM_SUPPORTED_PHP) < 0) {
+ if (version_compare($phpversion, Requirements::MINIMUM_SUPPORTED_PHP) < 0) {
$requirements['php']['description'] = t('Your PHP installation is too old. Drupal requires at least PHP %version. It is recommended to upgrade to PHP version %recommended or higher for the best ongoing support. See PHP\'s version support documentation and the Drupal 8 PHP requirements handbook page for more information.',

Here the difference:
MINIMUM_PHP checked before Drupal bootstrap and do not allow use the Drupal core with not compatible version of PHP

MINIMUM_SUPPORTED_PHP warn the administrator of the usage of outdated and not recommended version of the PHP

I think that documentation update we can do at the followup issue at any time, but remove deprecated constant only from the next major release.
Let's move forward and try to replace as much as possible API that left in the legacy includes files.

1. Needs re-roll.

2. I agree with #89. It's near RTBC! Needs followup due to #87 and #88.

Just reroll

Needs change record and issue summary update. Global PHP-related constants for minimum values are deprecated is outdated.

Added mentions that we also deprecate DRUPAL_MINIMUM_SUPPORTED_PHP constant. Added related issue where this constant was introduced.

Adressed #89. Now we can add @todo with the link to #3085402: Improve the documentation of Requirements::MINIMUM_SUPPORTED_PHP and Requirements::MINIMUM_PHP.

Noticed that docblock for Requirements::MINIMUM_PHP was outdated in comparison with DRUPAL_MINIMUM_PHP.
So I synchronized the documentation and also keep the same behavior for the request to install.php.

https://www.drupal.org/pift-ci-job/1423791
Unrelated test failure at PHP 7.
#3085512: Remove Class Constant Visibility from HelpTopicTwigTest which breaks tests at PHP 7

https://www.drupal.org/pift-ci-job/1423789
This looks like a random test failure.

Looks good to me. Test failure at PHP 7 is unrelated. See #96.

Needs re-roll. #3052703: Deprecate drupal_installation_attempted() was commited.

fast reroll

1. +++ b/core/composer.json
   @@ -180,7 +180,8 @@
   +        "files": ["lib/autoloader.php"]
   

   I think we should reconsider the location and name. The name because it has nothing to do autoloading. I think there is a good case for a file to exist like this. It'd be useful for doing other things like setting up class aliases. The location is also a bit odd because it's going against the README.txt in the same directory. This file is not "autoloadable" per se.

   Also if we do this we need to run $ composer update drupal/core in order to add the changes to composer.lock

   But see next comment. Imo this change should be delegate to a follow-up.

2. +++ b/core/install.php
   @@ -21,15 +21,6 @@
   -// Exit early if running an incompatible PHP version to avoid fatal errors.
   -// The minimum version is specified explicitly, as DRUPAL_MINIMUM_PHP is not
   -// yet available. It is defined in bootstrap.inc, but it is not possible to
   -// load that file yet as it would cause a fatal error on older versions of PHP.
   -if (version_compare(PHP_VERSION, '7.0.8') < 0) {
   -  print 'Your PHP installation is too old. Drupal requires at least PHP 7.0.8. See the <a href="https://www.drupal.org/requirements">system requirements</a> page for more information.';
   -  exit;
   -}
   

   I think this should be a follow-up and done in this issue. This isn't using a deprecated constant - yes it'd be great if it was but it's out-of-scope for deprecating the constants in boostrap.inc.

3. +++ b/core/lib/Drupal/Core/Requirements.php
   @@ -0,0 +1,51 @@
   +/**
   + * Defines PHP-related constants for use with Drupal.
   + */
   +final class Requirements {
   

   Great use of final!

#102.1 and #102.2: Oh, right, we have already an issue regarding the install.php file. So let's introduce that solution in #2910070: Figure out better solution for PHP version check in install.php.
So I'll revert those changes in the current patch as we have no deprecation replacements there. And I will introduce the patch with those changes in #2910070: Figure out better solution for PHP version check in install.php and postpone it on this issue.

1. #102 was addresed.

2. Needs change record update Global PHP-related constants for minimum values are deprecated.

I've been doing some thinking about this change. Whilst giving this a final review I started wondering why these constants weren't going on \Drupal. In #3 @mile23 wrote

Figuring out where to put these constants is awkward. I don’t like \Drupal in general, and it’s supposed to be about discovering services and not having constants for stuff. So really \Drupal::VERSION is misplaced. (There should be a Drupal\Core\Release class or something.)

I'm not sure that I agree with this. Firstly, \Drupal feels more like an application class that should have these application wide constants on. Secondly, it’s the service location parts of that class that are problematic not the constants.

The solution the current patch comes up with is to add a \Drupal\Core\Requirements class. I think that adding things to core/lib/Drupal/Core needs careful thought or that’s going to become a dumping ground and I'm not sure this belongs there.

I feel that there are 2 solutions:

• Move these to \Drupal
• Add a constants.php to our autoloader.

The first has problem that it doesn't solve things like #2909480: Move REQUIREMENT_* constants out of install.inc file (which is also creating a requirements class). The more I think about it the more I like the second because:

• there's no deprecation
• the constants become available to autoloaded code
• as constants.php grows it becomes a place to learn about all the core provided constants

The one downside is this approach is only available to core and not core modules/themes, or contrib or custom because they don't using composer to set up their autoloading. But I'm not sure that outweighs the advantages listed.

I have a patch to move these to \Drupal (attached) but I'm interested in other opinions on the core/constants.php idea.

From DX perspective I don't like the idea just to move constants into core/constants.php file as-is. Wrapping constants into a class made them more discoverable during coding in the IDE. So comparing the namespace naming \Drupal::MINIMUM_PHP vs \Drupal\Core\Requirements::MINIMUM_PHP , \Drupal looks more short.

So my proposals are to move constants to the namespaced class, but which one of the namespaces to choose - also interested in other opinions.

From DX perspective I don't like the idea just to move constants into core/constants.php file as-is. Wrapping constants into a class made them more discoverable during coding in the IDE.

IDEs discover global constants just fine in my experience.

Screenshot evidence for #107

Yes, exactly. That suggests all constant prefixed for different purposes.
Classes create the scope of the constants which can be defined for the specific purpose.

But if we want just to get rid of the include files, it's fine to just move the constant to autoloadable file as is, and then deprecate with removal in Drupal 10.

Re #105, what about putting the new constants on core/lib/DrupalInterface or similar? I recall an issue about preferring interfaces for constants because of some weirdness that can happen during autoloading? There are some early comments that allude to this, but memory foggy here.

Done re-roll for 9.1.x. Please review.

+++ b/core/includes/bootstrap.inc
@@ -22,12 +22,13 @@
+ * @deprecated in drupal:8.8.0 and is removed from drupal:9.0.0. Use

Versions in the deprecation messages needs to be updated.

Re #115 and #116, the patch is for 9.1.x, should not deprecation messages suppose to be removed in 9.x?

@jungle current dev is 9.1, it's where we can deprecate for 10.0

Thanks, @andypost! Versions updated.

1. When I do a code base search for "DRUPAL_MINIMUM_PHP", I still find it in the wrong places like: "core/install.php"
2. The change as described in the CR is not the same as the one from the patch.

Addressing #121.1 and updated min version to 7.3.0/7.3 according to the official documentation here

In order to minimize the need to include files containing constants in the global namespace, four global constants have been deprecated. and moved into core/lib/Drupal.php

Instead of DRUPAL_MINIMUM_PHP, use \Drupal::MINIMUM_PHP instead.
Instead of DRUPAL_MINIMUM_SUPPORTED_PHP, use \Drupal::MINIMUM_SUPPORTED_PHP instead.
Instead of DRUPAL_RECOMMENDED_PHP, use \Drupal::RECOMMENDED_PHP instead.
Instead of DRUPAL_MINIMUM_PHP_MEMORY_LIMIT, use \Drupal::MINIMUM_PHP_MEMORY_LIMIT instead.

CR updated

Updated API changes section of IS again according to the patch in #122

+++ b/core/includes/bootstrap.inc
@@ -22,12 +22,13 @@
+ *   \Drupal::MINIMUM_PHP instead.

@@ -38,10 +39,12 @@
+ *   \Drupal::MINIMUM_SUPPORTED_PHP instead.

@@ -50,10 +53,12 @@
+ *   \Drupal::RECOMMENDED_PHP instead.

@@ -62,10 +67,12 @@
+ *   \Drupal::MINIMUM_PHP_MEMORY_LIMIT instead.

The namespace/class is \Drupal or Drupal, not Requirements

@jungle: Thanks I missed that.

+++ b/core/install.php
@@ -22,7 +22,7 @@
 // Exit early if running an incompatible PHP version to avoid fatal errors.
-// The minimum version is specified explicitly, as DRUPAL_MINIMUM_PHP is not
+// The minimum version is specified explicitly, as \Drupal::MINIMUM_PHP is not
 // yet available. It is defined in bootstrap.inc, but it is not possible to
 // load that file yet as it would cause a fatal error on older versions of PHP.

Self-review, needs updating the inline comment further.