From Fedora Project Wiki
(Created page with "<!-- Self Contained or System Wide Change Proposal? Use this guide to determine to which category your proposed change belongs to. Self Contained Changes are: * changes to is...")
 
 
(9 intermediate revisions by 2 users not shown)
Line 54: Line 54:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1388477 #1388477]


Most of the work is done in my personal repository, see [http://rpms.remirepo.net/fedora/24/php71/x86_64/repoview/letter_p.group.html php71 repository for Fedora 24]
Most of the work is done in my personal repository, see [http://rpms.remirepo.net/fedora/24/php71/x86_64/repoview/letter_p.group.html php71 repository for Fedora 24]
Line 60: Line 60:
All extensions compatible with PHP 7.0 are ready for PHP 7.1
All extensions compatible with PHP 7.0 are ready for PHP 7.1


PHP 7.1.0RC6 was built in rawhide on Nov 14th 2016, and mass rebuild of (most of) the C extensions.
PHP 7.1.0 was released and built in rawhide on Dec 1st.


== Detailed Description ==
== Detailed Description ==
Line 65: Line 68:
Update the PHP stack in Fedora to latest version 7.1.x.
Update the PHP stack in Fedora to latest version 7.1.x.


* PHP 7.1.0RC3 was released Sep 29th
* PHP 7.1.0RC6 was released Nov 10th
* PHP 7.1.0 is planed for end of year.
* PHP 7.1.0 is planed for end of year.


Compatibility for PHP code is very good, while internal API have big changes, implying a major rewrite of C extensions.
Compatibility for PHP code is very good.
 
PHP 7.1 is the first compatible version with OpenSSL 1.1.


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 105: Line 110:


== How To Test ==
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.


Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
* The PHP stack (extensions and libraries) are monitored by Koschei, see the [https://apps.fedoraproject.org/koschei/groups/php?order_by=state%2C-started Koschei PHP group]
* install and play with your web applications


A good "how to test" should answer these four questions:
== User Experience ==


0. What special hardware / data / etc. is needed (if any)?
Developers and system administrators will have the great benefit or running the latest PHP version.
1. How do I prepare my system to test this change? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the change is
working like it's supposed to?
3. What are the expected results of those actions?
-->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
== User Experience ==
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)


== Dependencies ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
All php-* packages (and some *-php)
N/A (not a System Wide Change)  


== Contingency Plan ==
== Contingency Plan ==


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism: Drop not compatible packages.
 
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 144: Line 135:


== Documentation ==
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* [http://php.net/manual/en/migration71.php http://php.net/manual/en/migration71.php]
N/A (not a System Wide Change)
* [https://raw.githubusercontent.com/php/php-src/PHP-7.1/UPGRADING UPGRADING]
* [https://raw.githubusercontent.com/php/php-src/PHP-7.1/UPGRADING.INTERNALS UPGRADING.INTERNALS]


== Release Notes ==
== Release Notes ==
Line 156: Line 147:
-->
-->


[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF26]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Latest revision as of 04:58, 2 December 2016


PHP 7.1

Summary

Update the PHP stack in Fedora to latest version 7.1.x

Owner

Current status

Most of the work is done in my personal repository, see php71 repository for Fedora 24

All extensions compatible with PHP 7.0 are ready for PHP 7.1

PHP 7.1.0RC6 was built in rawhide on Nov 14th 2016, and mass rebuild of (most of) the C extensions.

PHP 7.1.0 was released and built in rawhide on Dec 1st.

Detailed Description

Update the PHP stack in Fedora to latest version 7.1.x.

  • PHP 7.1.0RC6 was released Nov 10th
  • PHP 7.1.0 is planed for end of year.

Compatibility for PHP code is very good.

PHP 7.1 is the first compatible version with OpenSSL 1.1.

Benefit to Fedora

Provides the latest PHP version to developers and system administrators.


Scope

  • Proposal owners: Check Koschei status. Test with latest version to ensure compatibility. Work with upstream on bug fixing.


  • Other developers: N/A (not a System Wide Change)
  • Release engineering: needed mass rebuild (C extensions) done by change owner.
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

  • The PHP stack (extensions and libraries) are monitored by Koschei, see the Koschei PHP group
  • install and play with your web applications

User Experience

Developers and system administrators will have the great benefit or running the latest PHP version.


Dependencies

All php-* packages (and some *-php)

Contingency Plan

  • Contingency mechanism: Drop not compatible packages.
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

Release Notes