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
#2152073: Bump Drupal core's PHP requirement to 5.4.2 bumped Drupal core's PHP requirement, but between making those patches and the time they were committed, #2176065: Introduce a composer.json for Drupal\Component\Utility was committed as well, which still contained the original PHP 5.3.10 requirement.
Proposed resolution
Bump this requirement to 5.4.2 as well.
Remaining tasks
None.
User interface changes
None.
API changes
None, since this code was supposed to be compliant with PHP 5.4.2 anyway.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | drupal_2210257_1.patch | 443 bytes | Xano |
Comments
Comment #1
XanoComment #2
sunComment #3
EclipseGc CreditAttribution: EclipseGc commentedI'm not sure I see a reason to do this. Utility doesn't require 5.4.x, do you really want to force it on people who don't need it? The composer file actually means stuff, so... I'd personally say let's not do this. I'm closing this, if you have serious reasoning to the contrary, feel free to re-open, but unless Utility actually needs 5.4.x my position would be that it has no need to require it.
Eclipse
Comment #4
XanoDrupal's system requirements, as a project, say our Drupal 8 code base in its entirety needs PHP 5.4.2. Some parts will work fine on PHP 4, others on 5.2 or 5.3, and only few bits of code will require 5.4. The code base's required version is still 5.4.2, though.
Even though \Drupal\Component\Utility's composer.json only covers part of our code base, this still falls within our global requirement for PHP 5.4.2. If we don't want that, then we should move this part of our code base to a separate project and include it in core.
Comment #5
Xano@EclipseGc is a convincing man indeed.
Comment #6
sunFWIW, I'm not convinced.
I can see and understand @EclipseGc's point, but if we go that route, then someone is going to be responsible for double-checking that the actual code in Utility is still compatible with PHP 5.3 prior to the release of Drupal 8.0.0.
I and everyone else is certainly not going to remember that the PHP compatibility version in composer.json needs to be updated, as soon as the first PHP 5.4 code line is introduced in Utility (which is only a matter of days). Our tests won't notice.
Therefore, I'd prefer to update the PHP compatibility version for the reason of consistency, and to prevent that a stale and wrong compatibility version is stated in there.
Comment #7
Xano@EclipseGc told me he is working on getting the components out of the Drupal core project. If that works, I see no reason to bump the requirement. If we end up shipping D8 with these components, I think it may be a good idea to bump the requirement after all. On the other hand, we can also bump now, and lower the requirement later once we removed the components from core and are sure no PHP 5.4 (for instance) code was introduced in the meantime.
Comment #8
sunTo my knowledge, @Dries only agreed to having composer.json files for the sake of performing subtree splits from core (in the same way Symfony is doing it).
I do not think that there is an agreement to moving the components in
Drupal\Componententirely out of the core code base. It is very unlikely that's going to happen for D8.Comment #9
EclipseGc CreditAttribution: EclipseGc commentedSun is correct, the code is unlikely to change its position physically, it will just be able to be served independently, it won't actually be removed from core.
I don't think this has any bearing personally. We need to get used to the fact that these Component things exist, and that they have a life of their own and need the same respect we afford Drupal itself in terms of dotting our i's and crossing our t's. To that end, a LOT of people seem to understand that at some level as many of the people involved in the code for any component get asked to review that code before it's committed. Numerous times during the D8 cycle I've reviewed a patch to plugins that would have made it NOT a component (functionally) anymore and my feedback has been utilized in order to keep that split appropriately respected. That gives me a lot of hope that we can and will generally succeed at respecting the composer files once everyone understands what they are and what they mean. That's not to say we won't have missteps, but I think a bigger problem could be caused by caving on this point too earlier. If we find this is seriously problematic, or that we're just consistently failing at it, we can always revisit a policy at some later date. It will not break BC for Drupal itself to do so.
Eclipse