Bug 1949319

Summary: Rebase PHP to 8.0
Product: Red Hat Enterprise Linux 9 Reporter: Neal Gompa <ngompa13>
Component: phpAssignee: Remi Collet <rcollet>
Status: CLOSED CURRENTRELEASE QA Contact: icesalov
Severity: unspecified Docs Contact: Lenka Špačková <lkuprova>
Priority: unspecified    
Version: CentOS StreamCC: bnater, bstinson, carl, icesalov, jorton, jwboyer, rcollet
Target Milestone: betaKeywords: Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: php-8.0.6-3.el9 Doc Type: Enhancement
Doc Text:
.RHEL 9 includes `PHP 8.0` RHEL 9 is distributed with `PHP 8.0`, which provides a number of bug fixes and enhancements over version 7.4. Notable enhancements include: * New named arguments are order-independent and self-documented, and enable you to specify only required parameters. * New attributes enable you to use structured metadata with PHP's native syntax. * New union types enable you to use native union type declarations that are validated at runtime instead of PHPDoc annotations for a combination of types. * Internal functions now more consistently raise an Error exception instead of warnings if parameter validation fails. * New Just-In-Time compilation engines significantly improve application performance. * The `Xdebug` debugging and productivity extension for PHP has been updated to version 3. This version introduces major changes in functionality and configuration compared to `Xdebug 2`. `PHP 8.0` is the initial version of this Application Stream, which you can install easily as an RPM package. Additional `PHP` versions will be provided as modules with a shorter life cycle in future minor releases of RHEL 9. For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/installing_and_using_dynamic_programming_languages#assembly_using-the-php-scripting-language_installing-and-using-dynamic-programming-languages[Using the PHP scripting language].
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-12-07 21:35:16 UTC Type: Enhancement
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Neal Gompa 2021-04-14 01:43:18 UTC
Description of problem:
PHP 8.0 released on November 2020 and is currently present in Fedora Rawhide (to become Fedora 35)[0]. For RHEL 9, the default PHP version should be based on the the latest version of the PHP stack to set up for long-term maintenance and usability. At this time, that is PHP 8.0 (though I expect GA will have PHP 8.1).

[0]: https://fedoraproject.org/wiki/Changes/php80

Comment 1 Remi Collet 2021-04-16 14:04:31 UTC
WIP on https://gitlab.com/remirh/centos_rpms_php/-/commits/bz1949319

Probably going to wait for 8.0.5 in 2 weeks

Comment 20 Neal Gompa 2021-10-11 14:20:12 UTC
> `PHP 8.0` is the initial version of this Application Stream, which can be simply installed from an RPM metapackage. Additional `PHP` versions will be provided as modules with a shorter life cycle in the future minor releases of RHEL 9. 

Wouldn't it make sense to upgrade the non-modular package and provide the older versions as non-default modules if the initial version isn't supported throughout the life of a RHEL release?

Comment 26 Joe Orton 2022-04-28 15:34:36 UTC
(In reply to Neal Gompa from comment #20)
> > `PHP 8.0` is the initial version of this Application Stream, which can be simply installed from an RPM metapackage. Additional `PHP` versions will be provided as modules with a shorter life cycle in the future minor releases of RHEL 9. 
> 
> Wouldn't it make sense to upgrade the non-modular package and provide the
> older versions as non-default modules if the initial version isn't supported
> throughout the life of a RHEL release?

To belatedly answer this (sorry Neal), it remains a goal that an application deployed on 9.0 will work the same if deployed the same way on a later update to RHEL9, which we definitely could not guarantee if PHP was rebased to a later version (across minor or major versions, which break BC).