├── .github └── workflows │ └── docs.yml ├── LICENSE ├── README.rst ├── archive └── end-of-life.rst ├── coding-standards-and-naming.rst ├── feature-proposals.rst ├── release-process.rst ├── security-classification.rst ├── security-policies.rst └── third-party-code.rst /.github/workflows/docs.yml: -------------------------------------------------------------------------------- 1 | name: Docs 2 | on: 3 | push: 4 | branches: 5 | - master 6 | paths: 7 | - '*.rst' 8 | pull_request: 9 | paths: 10 | - '*.rst' 11 | jobs: 12 | pages: 13 | runs-on: ubuntu-22.04 14 | permissions: 15 | pages: write 16 | id-token: write 17 | steps: 18 | - name: git checkout 19 | uses: actions/checkout@v4 20 | - name: Install dependencies 21 | run: pip install sphinx-design sphinxawesome-theme rstfmt 22 | - name: Check formatting 23 | run: rstfmt --check -w 80 *.rst 24 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Attribution 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution 4.0 International Public License 58 | 59 | By exercising the Licensed Rights (defined below), You accept and agree 60 | to be bound by the terms and conditions of this Creative Commons 61 | Attribution 4.0 International Public License ("Public License"). To the 62 | extent this Public License may be interpreted as a contract, You are 63 | granted the Licensed Rights in consideration of Your acceptance of 64 | these terms and conditions, and the Licensor grants You such rights in 65 | consideration of benefits the Licensor receives from making the 66 | Licensed Material available under these terms and conditions. 67 | 68 | 69 | Section 1 -- Definitions. 70 | 71 | a. Adapted Material means material subject to Copyright and Similar 72 | Rights that is derived from or based upon the Licensed Material 73 | and in which the Licensed Material is translated, altered, 74 | arranged, transformed, or otherwise modified in a manner requiring 75 | permission under the Copyright and Similar Rights held by the 76 | Licensor. For purposes of this Public License, where the Licensed 77 | Material is a musical work, performance, or sound recording, 78 | Adapted Material is always produced where the Licensed Material is 79 | synched in timed relation with a moving image. 80 | 81 | b. Adapter's License means the license You apply to Your Copyright 82 | and Similar Rights in Your contributions to Adapted Material in 83 | accordance with the terms and conditions of this Public License. 84 | 85 | c. Copyright and Similar Rights means copyright and/or similar rights 86 | closely related to copyright including, without limitation, 87 | performance, broadcast, sound recording, and Sui Generis Database 88 | Rights, without regard to how the rights are labeled or 89 | categorized. For purposes of this Public License, the rights 90 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 91 | Rights. 92 | 93 | d. Effective Technological Measures means those measures that, in the 94 | absence of proper authority, may not be circumvented under laws 95 | fulfilling obligations under Article 11 of the WIPO Copyright 96 | Treaty adopted on December 20, 1996, and/or similar international 97 | agreements. 98 | 99 | e. Exceptions and Limitations means fair use, fair dealing, and/or 100 | any other exception or limitation to Copyright and Similar Rights 101 | that applies to Your use of the Licensed Material. 102 | 103 | f. Licensed Material means the artistic or literary work, database, 104 | or other material to which the Licensor applied this Public 105 | License. 106 | 107 | g. Licensed Rights means the rights granted to You subject to the 108 | terms and conditions of this Public License, which are limited to 109 | all Copyright and Similar Rights that apply to Your use of the 110 | Licensed Material and that the Licensor has authority to license. 111 | 112 | h. Licensor means the individual(s) or entity(ies) granting rights 113 | under this Public License. 114 | 115 | i. Share means to provide material to the public by any means or 116 | process that requires permission under the Licensed Rights, such 117 | as reproduction, public display, public performance, distribution, 118 | dissemination, communication, or importation, and to make material 119 | available to the public including in ways that members of the 120 | public may access the material from a place and at a time 121 | individually chosen by them. 122 | 123 | j. Sui Generis Database Rights means rights other than copyright 124 | resulting from Directive 96/9/EC of the European Parliament and of 125 | the Council of 11 March 1996 on the legal protection of databases, 126 | as amended and/or succeeded, as well as other essentially 127 | equivalent rights anywhere in the world. 128 | 129 | k. You means the individual or entity exercising the Licensed Rights 130 | under this Public License. Your has a corresponding meaning. 131 | 132 | 133 | Section 2 -- Scope. 134 | 135 | a. License grant. 136 | 137 | 1. Subject to the terms and conditions of this Public License, 138 | the Licensor hereby grants You a worldwide, royalty-free, 139 | non-sublicensable, non-exclusive, irrevocable license to 140 | exercise the Licensed Rights in the Licensed Material to: 141 | 142 | a. reproduce and Share the Licensed Material, in whole or 143 | in part; and 144 | 145 | b. produce, reproduce, and Share Adapted Material. 146 | 147 | 2. Exceptions and Limitations. For the avoidance of doubt, where 148 | Exceptions and Limitations apply to Your use, this Public 149 | License does not apply, and You do not need to comply with 150 | its terms and conditions. 151 | 152 | 3. Term. The term of this Public License is specified in Section 153 | 6(a). 154 | 155 | 4. Media and formats; technical modifications allowed. The 156 | Licensor authorizes You to exercise the Licensed Rights in 157 | all media and formats whether now known or hereafter created, 158 | and to make technical modifications necessary to do so. The 159 | Licensor waives and/or agrees not to assert any right or 160 | authority to forbid You from making technical modifications 161 | necessary to exercise the Licensed Rights, including 162 | technical modifications necessary to circumvent Effective 163 | Technological Measures. For purposes of this Public License, 164 | simply making modifications authorized by this Section 2(a) 165 | (4) never produces Adapted Material. 166 | 167 | 5. Downstream recipients. 168 | 169 | a. Offer from the Licensor -- Licensed Material. Every 170 | recipient of the Licensed Material automatically 171 | receives an offer from the Licensor to exercise the 172 | Licensed Rights under the terms and conditions of this 173 | Public License. 174 | 175 | b. No downstream restrictions. You may not offer or impose 176 | any additional or different terms or conditions on, or 177 | apply any Effective Technological Measures to, the 178 | Licensed Material if doing so restricts exercise of the 179 | Licensed Rights by any recipient of the Licensed 180 | Material. 181 | 182 | 6. No endorsement. Nothing in this Public License constitutes or 183 | may be construed as permission to assert or imply that You 184 | are, or that Your use of the Licensed Material is, connected 185 | with, or sponsored, endorsed, or granted official status by, 186 | the Licensor or others designated to receive attribution as 187 | provided in Section 3(a)(1)(A)(i). 188 | 189 | b. Other rights. 190 | 191 | 1. Moral rights, such as the right of integrity, are not 192 | licensed under this Public License, nor are publicity, 193 | privacy, and/or other similar personality rights; however, to 194 | the extent possible, the Licensor waives and/or agrees not to 195 | assert any such rights held by the Licensor to the limited 196 | extent necessary to allow You to exercise the Licensed 197 | Rights, but not otherwise. 198 | 199 | 2. Patent and trademark rights are not licensed under this 200 | Public License. 201 | 202 | 3. To the extent possible, the Licensor waives any right to 203 | collect royalties from You for the exercise of the Licensed 204 | Rights, whether directly or through a collecting society 205 | under any voluntary or waivable statutory or compulsory 206 | licensing scheme. In all other cases the Licensor expressly 207 | reserves any right to collect such royalties. 208 | 209 | 210 | Section 3 -- License Conditions. 211 | 212 | Your exercise of the Licensed Rights is expressly made subject to the 213 | following conditions. 214 | 215 | a. Attribution. 216 | 217 | 1. If You Share the Licensed Material (including in modified 218 | form), You must: 219 | 220 | a. retain the following if it is supplied by the Licensor 221 | with the Licensed Material: 222 | 223 | i. identification of the creator(s) of the Licensed 224 | Material and any others designated to receive 225 | attribution, in any reasonable manner requested by 226 | the Licensor (including by pseudonym if 227 | designated); 228 | 229 | ii. a copyright notice; 230 | 231 | iii. a notice that refers to this Public License; 232 | 233 | iv. a notice that refers to the disclaimer of 234 | warranties; 235 | 236 | v. a URI or hyperlink to the Licensed Material to the 237 | extent reasonably practicable; 238 | 239 | b. indicate if You modified the Licensed Material and 240 | retain an indication of any previous modifications; and 241 | 242 | c. indicate the Licensed Material is licensed under this 243 | Public License, and include the text of, or the URI or 244 | hyperlink to, this Public License. 245 | 246 | 2. You may satisfy the conditions in Section 3(a)(1) in any 247 | reasonable manner based on the medium, means, and context in 248 | which You Share the Licensed Material. For example, it may be 249 | reasonable to satisfy the conditions by providing a URI or 250 | hyperlink to a resource that includes the required 251 | information. 252 | 253 | 3. If requested by the Licensor, You must remove any of the 254 | information required by Section 3(a)(1)(A) to the extent 255 | reasonably practicable. 256 | 257 | 4. If You Share Adapted Material You produce, the Adapter's 258 | License You apply must not prevent recipients of the Adapted 259 | Material from complying with this Public License. 260 | 261 | 262 | Section 4 -- Sui Generis Database Rights. 263 | 264 | Where the Licensed Rights include Sui Generis Database Rights that 265 | apply to Your use of the Licensed Material: 266 | 267 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 268 | to extract, reuse, reproduce, and Share all or a substantial 269 | portion of the contents of the database; 270 | 271 | b. if You include all or a substantial portion of the database 272 | contents in a database in which You have Sui Generis Database 273 | Rights, then the database in which You have Sui Generis Database 274 | Rights (but not its individual contents) is Adapted Material; and 275 | 276 | c. You must comply with the conditions in Section 3(a) if You Share 277 | all or a substantial portion of the contents of the database. 278 | 279 | For the avoidance of doubt, this Section 4 supplements and does not 280 | replace Your obligations under this Public License where the Licensed 281 | Rights include other Copyright and Similar Rights. 282 | 283 | 284 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 285 | 286 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 287 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 288 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 289 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 290 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 291 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 292 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 293 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 294 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 295 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 296 | 297 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 298 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 299 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 300 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 301 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 302 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 303 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 304 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 305 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 306 | 307 | c. The disclaimer of warranties and limitation of liability provided 308 | above shall be interpreted in a manner that, to the extent 309 | possible, most closely approximates an absolute disclaimer and 310 | waiver of all liability. 311 | 312 | 313 | Section 6 -- Term and Termination. 314 | 315 | a. This Public License applies for the term of the Copyright and 316 | Similar Rights licensed here. However, if You fail to comply with 317 | this Public License, then Your rights under this Public License 318 | terminate automatically. 319 | 320 | b. Where Your right to use the Licensed Material has terminated under 321 | Section 6(a), it reinstates: 322 | 323 | 1. automatically as of the date the violation is cured, provided 324 | it is cured within 30 days of Your discovery of the 325 | violation; or 326 | 327 | 2. upon express reinstatement by the Licensor. 328 | 329 | For the avoidance of doubt, this Section 6(b) does not affect any 330 | right the Licensor may have to seek remedies for Your violations 331 | of this Public License. 332 | 333 | c. For the avoidance of doubt, the Licensor may also offer the 334 | Licensed Material under separate terms or conditions or stop 335 | distributing the Licensed Material at any time; however, doing so 336 | will not terminate this Public License. 337 | 338 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 339 | License. 340 | 341 | 342 | Section 7 -- Other Terms and Conditions. 343 | 344 | a. The Licensor shall not be bound by any additional or different 345 | terms or conditions communicated by You unless expressly agreed. 346 | 347 | b. Any arrangements, understandings, or agreements regarding the 348 | Licensed Material not stated herein are separate from and 349 | independent of the terms and conditions of this Public License. 350 | 351 | 352 | Section 8 -- Interpretation. 353 | 354 | a. For the avoidance of doubt, this Public License does not, and 355 | shall not be interpreted to, reduce, limit, restrict, or impose 356 | conditions on any use of the Licensed Material that could lawfully 357 | be made without permission under this Public License. 358 | 359 | b. To the extent possible, if any provision of this Public License is 360 | deemed unenforceable, it shall be automatically reformed to the 361 | minimum extent necessary to make it enforceable. If the provision 362 | cannot be reformed, it shall be severed from this Public License 363 | without affecting the enforceability of the remaining terms and 364 | conditions. 365 | 366 | c. No term or condition of this Public License will be waived and no 367 | failure to comply consented to unless expressly agreed to by the 368 | Licensor. 369 | 370 | d. Nothing in this Public License constitutes or may be interpreted 371 | as a limitation upon, or waiver of, any privileges and immunities 372 | that apply to the Licensor or You, including from the legal 373 | processes of any jurisdiction or authority. 374 | 375 | 376 | ======================================================================= 377 | 378 | Creative Commons is not a party to its public 379 | licenses. Notwithstanding, Creative Commons may elect to apply one of 380 | its public licenses to material it publishes and in those instances 381 | will be considered the “Licensor.” The text of the Creative Commons 382 | public licenses is dedicated to the public domain under the CC0 Public 383 | Domain Dedication. Except for the limited purpose of indicating that 384 | material is shared under a Creative Commons public license or as 385 | otherwise permitted by the Creative Commons policies published at 386 | creativecommons.org/policies, Creative Commons does not authorize the 387 | use of the trademark "Creative Commons" or any other trademark or logo 388 | of Creative Commons without its prior written consent including, 389 | without limitation, in connection with any unauthorized modifications 390 | to any of its public licenses or any other arrangements, 391 | understandings, or agreements concerning use of licensed material. For 392 | the avoidance of doubt, this paragraph does not form part of the 393 | public licenses. 394 | 395 | Creative Commons may be contacted at creativecommons.org. 396 | 397 | -------------------------------------------------------------------------------- /README.rst: -------------------------------------------------------------------------------- 1 | ########## 2 | Policies 3 | ########## 4 | 5 | This repository contains a list of policies that the PHP Project has adopted 6 | through its RFC process to govern releases, voting, and naming guidelines. 7 | 8 | It contains the following items: 9 | 10 | - `Release Process `_: When releases are made, how they 11 | are named, our policy on version numbers, and the process on making releases. 12 | 13 | - `Feature Proposals (RFCs) `_: How to propose new 14 | features to PHP. 15 | 16 | - `Coding Standards `_: How to name new 17 | classes, methods, extensions, and functions. 18 | 19 | - `Security Classification `_: What we consider as 20 | security issues, their severity, and how to report issues. 21 | 22 | - `Security Policies and Process `_: Policies and 23 | process on how and when to update the `security.txt 24 | `_ file on https://www.php.net. 25 | 26 | - `Third-Party code `_: The circumstances under which the 27 | PHP project will use PHP code written by third parties in the ecosystem. 28 | 29 | ************ 30 | Formatting 31 | ************ 32 | 33 | The files in this documentation are formatted using the `rstfmt 34 | `_ tool, which you can install with: 35 | 36 | .. code:: 37 | 38 | python3 -m venv ~/install/rstfmt 39 | ~/install/rstfmt/bin/pip3 install rstfmt 40 | sudo ln -s ~/install/rstfmt/bin/rstfmt /usr/local/bin/rstfmt 41 | 42 | Please run the tool before submitting a pull request: 43 | 44 | .. code:: 45 | 46 | rstfmt -w 80 *.rst 47 | -------------------------------------------------------------------------------- /archive/end-of-life.rst: -------------------------------------------------------------------------------- 1 | Historical Support Timelines 2 | ---------------------------- 3 | 4 | PHP 5.3 End Of Life 5 | ~~~~~~~~~~~~~~~~~~~ 6 | 7 | **From:** https://wiki.php.net/rfc/php53eol 8 | 9 | Introduction 10 | ```````````` 11 | 12 | The purpose of this RFC is to define when the PHP 5.3 series will no longer be 13 | supported. 14 | 15 | As PHP 5.3 was released before the new release process was defined and 16 | implemented, we have to define a clear EOL 1). 17 | 18 | Even if the 5.3 release manager already stated something about the status of 19 | PHP 5.3, it is critical for us to have a clear and open decision. PHP 5.3 is 20 | still the most widely (maintained) branch and many projects rely on it as a 21 | minimum version. It is also important to keep in mind that we won't have this 22 | problem anymore in 5.4 or later and the life cycle is already clearly defined 23 | by the release process RFC. 24 | 25 | Options 26 | ``````` 27 | 28 | #. Two years, one normal fixes and one security fixes only, announce with the next 5.3 release 29 | #. Two years, one normal fixes and one security fixes only, announce with 5.5 final release 30 | #. Two years with security fixes only, announce with the next 5.3 release 31 | #. Two years with security fixes only, announce with 5.5 final release 32 | #. One year with normal and security fixes, announce with the next 5.3 release 33 | #. One year with normal and security fixes, announce with 5.5 final release 34 | #. One year with security fixes only, announce with the next 5.3 release 35 | #. One year with security fixes only, announce with 5.5 final release 36 | 37 | Decision 38 | ```````` 39 | 40 | One year with security fixes only, announce with 5.5 final release 41 | 42 | 43 | PHP 5.6 Support Timeline 44 | ~~~~~~~~~~~~~~~~~~~~~~~~ 45 | 46 | **From:** https://wiki.php.net/rfc/php56timeline 47 | 48 | Background 49 | `````````` 50 | 51 | The release of PHP 7.0 is the first time a major version of PHP is released 52 | under the new Release Process RFC. While the RFC did outline rules for major 53 | versions, most of the discussion prior to the RFC, as well as all of the 54 | experience we've gained on the ground since its introduction dealt with how we 55 | deal with minor versions, as back then a major version wasn't actively being 56 | discussed. In addition, the release of PHP 7.0 happened substantially later 57 | than the 'standard' mid-year release cycle that most prior versions of PHP 58 | adhered to. 59 | 60 | The currently published timeline for PHP 5.6 suggests an end to active support 61 | on August 28, 2016 and end to security support on August 28, 2017 - 62 | approximately 8 months & 20 months (respectively) after the release of PHP 63 | 7.0. Many consider these timeline inadequate for two key reasons: 64 | 65 | #. In absolute terms, 20 months to upgrade the entire worldwide PHP codebase - 66 | after which an app that wasn't migrated would be exposed to security 67 | vulnerabilities - appears to be on the short side. 68 | #. In relative terms, it seems awkward that people would have more time to 69 | upgrade from PHP 5.5 to 5.6 - an upgrade that is typically completely 70 | painless - than they do to upgrade from 5.6 to 7.0 - an upgrade which 71 | requires certain levels of code auditing and extensive testing. 72 | 73 | In addition, PHP 7 breaks source-level compatibility with PHP 5.x - which 74 | means extensions will not work (or even build) on PHP 7 without substantial 75 | refactoring. This refactoring typically amounts to much more than just fixing 76 | some compilation errors, due to fundamental changes to the underlying data 77 | structures of the engine. Extending the support period for PHP 5 will allow 78 | users of custom extensions - as well as PECL extensions which haven't yet been 79 | upgraded - to have more time to port and test them, as well as their code that 80 | uses them. It's worth noting that much of the development effort of PHP 7 81 | since the introduction of the PHPNG engine was focused around porting 82 | extensions to build and work on PHP 7 - this is not an easy task. 83 | 84 | Proposal 85 | ```````` 86 | 87 | It is proposed to reschedule both the End of Active Support and End of 88 | Security Support to provide the PHP userbase a longer, but still clear upgrade 89 | timeline. Most people feel that it is more important to further push the End 90 | of Security Support date, compared to the End of Active Support date. 91 | 92 | This RFC recommends to extend the Active Support period to a full year, 93 | followed by two additional years of Security Support. In total, it provides 94 | three different options to choose from: 95 | 96 | #. 1 year of Active Support (ending Dec 31, 2016), plus 2 years of Security Support (ending Dec 31, 2018). 97 | #. 1 year of Active Support (ending Dec 31, 2016), plus 1 year of Security Support (ending Dec 31, 2017). 98 | #. No change - 8 months of Active Support (ending Aug 28, 2016), plus 1 year of Security Support (ending Aug 28, 2017). 99 | 100 | There are two main downsides to pushing the support dates for PHP 5.6: 101 | 102 | - Obviously, it will require the developers of PHP (us) to maintain it for a 103 | longer period of time, investing more time and effort than we would 104 | otherwise have to. 105 | - Extending the end of support dates may reduce the sense of urgency of 106 | people to upgrade, and may cause people who would have otherwise upgraded 107 | sooner to upgrade later. 108 | 109 | That said, many believe that sticking with the current timeline (option #3) is 110 | simply too aggressive, and we should at least go for option #2 as it gives 111 | people at least the same amount of time they had to upgrade from 5.5 to 5.6, 112 | to upgrade from 5.6 to 7.0. 113 | 114 | Further, given the 5.6 -> 7.0 upgrade is more difficult and time consuming - 115 | the recommendation of this RFC is to go with option #1. The importance of 116 | giving users a bit more time to upgrade was also alluded to in the PHP 5.7 117 | RFC, although it was rejected - mainly due to concerns about defocusing the 118 | efforts of releasing PHP 7.0 - concerns which are no longer relevant now that 119 | 7.0 has been successfully released. 120 | 121 | Decision 122 | ```````` 123 | 124 | - Extend the support timeline of PHP 5? — **Yes** 125 | - Extend the support timeline to: 1 year Active Support, 2 years Security Support 126 | 127 | Name of Next Release of PHP 128 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 129 | 130 | **From:** https://wiki.php.net/rfc/php6 131 | 132 | Introduction 133 | ```````````` 134 | 135 | There has been some debate over what the name of the next major release of 136 | PHP, to succeed the PHP 5.x series, should be called. This RFC is an attempt 137 | to settle the matter once and for all. 138 | 139 | This RFC proposes that the next major version of PHP shall be named either PHP 140 | 6 or PHP 7, based on the outcome of this vote. In the following arguments for 141 | both sides are presented. 142 | 143 | Historical context 144 | `````````````````` 145 | 146 | The reason why this question even comes up, is that there has been a previous 147 | attempt at a new major version, which was started in 2005 and abandoned in 148 | 2010 due to difficulties in the Unicode implementation. Apart from 149 | language-integrated Unicode support, most features added for that version were 150 | integrated either in PHP 5.3 or PHP 5.4. 151 | 152 | This previous attempt at a new major version was also developed under the name 153 | of PHP 6 and as such there are various resources referring to it, including a 154 | number of books. There is concern that there might be confusion between the 155 | abandoned previous attempt and the work that is currently happening. 156 | 157 | The Case for PHP 7 158 | `````````````````` 159 | 160 | The case for choosing 7 as the next major version for PHP is comprised from 2 161 | key elements - there are no good reasons not to do it, and several good 162 | reasons to do it. 163 | 164 | No good reasons NOT to skip version 6 165 | ##################################### 166 | 167 | Regarding the first element, it seems that many people are concerned that if 168 | we skip a version, we somehow cause confusion or break away from our 169 | versioning scheme. 170 | 171 | The main confusion point cited by proponents of 'PHP 6' was that people will 172 | wonder 'how come we suddenly have PHP 7 and without having PHP 6?' - however, 173 | this is really much more of a trivia question than a cause for confusion. For 174 | obvious reasons, it will be clear that 7 is the latest version and even if 175 | there is 6 out there, 7 is newer and better. 176 | 177 | We also wouldn't be breaking away or even changing our current versioning 178 | scheme. We're only skipping a version, while keeping everything about our 179 | versioning scheme intact. 180 | 181 | Strong reasons of why we actually should skip version 6 into 7 182 | ############################################################## 183 | 184 | There are several reasons of why we shouldn't reuse version 6 for the next 185 | major version of PHP. 186 | 187 | - First and foremost, PHP 6 already existed and it was something completely 188 | different. The decimal system (or more accurately the infinite supply of 189 | numbers we have) makes it easy for us to skip a version, with plenty more 190 | left for future versions to come. 191 | - While it's true that the other PHP 6 never reached General Availability, it 192 | was still a very widely published and well-known project conducted by 193 | php.net that will share absolutely nothing with the version that is under 194 | discussion now. Anybody who knew what PHP 6 is (and there are many) will 195 | have a strong misconception in his or her mind as to the contents and 196 | features of this new upcoming version (essentially, that it's all about 197 | Unicode). 198 | - PHP 6, the original PHP 6, has been discussed in detail in many PHP 199 | conferences. It was taught to users as a done-deal, including detailed 200 | explanations about features and behavior (by php.net developers, not 'evil' 201 | book authors). 202 | - PHP 6 was widely known not only within the Internals community, but around 203 | the PHP community at large. It was a high profile project that many - if 204 | not most - PHP community members knew about. 205 | - There's lots of PHP 6 information, about the original PHP 6, that exists 206 | around the web. Books are the smallest part of the problem. 207 | - Unlike the 'trivia question' of 'why did we skip into 7?', reusing version 208 | 6 is likely to call real confusion in people's minds, with ample 209 | information on two completely different versions with entirely different 210 | feature sets that have the exact same name. 211 | - Skipping versions isn't unprecedented or uncommon in both open source 212 | projects and commercial products. MariaDB, jumped all the way up to version 213 | 10.0 to avoid confusion, Netscape Communicator skipped version 5.0 directly 214 | into 6.0, and Symantec skipped version 13. Each and every one of those had 215 | different reasons for the skipping, but the common denominator is that 216 | skipping versions is hardly a big deal. 217 | - Version 6 is generally associated with failure in the world of dynamic 218 | languages. PHP 6 was a failure; Perl 6 was a failure. It's actually 219 | associated with failure also outside the dynamic language world - MySQL 6 220 | also existed but never released. The perception of version 6 as a failure - 221 | not as a superstition but as a real world fact (similar to the association 222 | of the word 'Vista' with failure) - will reflect badly on this PHP version. 223 | - The case for 6 is mostly a rebuttal of some of the points above, but 224 | without providing a strong case for why we *shouldn't* skip version 6. If 225 | we go with PHP 7, the worst case scenario is that we needlessly skipped a 226 | version. We'd still have an infinite supply of major versions at our 227 | disposal for future use. If, however, we pick 6 instead of 7 - the worst 228 | case scenario is widespread confusion in our community and potential 229 | negative perception about this version. 230 | 231 | As a special non serious bonus, 7 is perceived as a lucky number in both the 232 | Western world and Chinese culture. A little bit of luck never hurt anybody. 233 | http://en.wikipedia.org/wiki/Numbers_in_Chinese_culture (no, we're not truly 234 | seeing it as a real advantage - the case for 7 is very strong without it). 235 | 236 | Summary 237 | ####### 238 | 239 | Version 6 is already taken by a highly publicized project that is in the minds 240 | of a very large chunk of PHP developers, internals and general PHP community 241 | alike. 242 | 243 | We risk nothing by calling it PHP 7. We risk confusion and negative perception 244 | if we insist on reusing 6 for a completely different project. 245 | 246 | Taking a risk that stands to yield absolutely no reward is not a good 247 | strategy. 248 | 249 | The Case for PHP 6 250 | `````````````````` 251 | 252 | - According to our current release process and semantic versioning, the next 253 | major version after PHP 5 should be PHP 6. Unless there are very strong 254 | reasons to the contrary, we should not abandon our current version 255 | numbering scheme. 256 | - While there exists a number of resources about the previous attempt at a 257 | PHP 6 release, these will be quickly displaced once PHP 6 is actually 258 | released. This applies both to blog posts, which will be (and partially 259 | already are) displaced by newer content, and books, which will receive 260 | negative reviews because they do not actually cover the version of PHP they 261 | claim to cover. 262 | - By now there are also many resources which refer to the next major version 263 | as “PHP 6”, without having any relation to the abandoned previous attempt. 264 | This includes anything from blog posts and discussions about features for 265 | the upcoming version, to RFCs and design documents in this wiki. Calling 266 | the next major version “PHP 7” instead will cause confusion in this 267 | direction. 268 | - In OTR discussions about a new major version, it is nearly always referred 269 | to as “PHP 6”. Given that the current version is PHP 5, people 270 | understandably jump to the conclusion that the next one will be “PHP 6” and 271 | refer to it as such. In the minds of many devs “PHP 6” is already deeply 272 | ingrained as the name of the next major. 273 | - While many participants on the internals mailing list were involved in the 274 | original PHP 6 effort and as such are acutely aware of its existence, the 275 | larger PHP community is not. While discussing this RFC with various 276 | developers, many did not really understand why this was even a question, 277 | because they were no more than vaguely aware that there was something like 278 | PHP 6 in the past. As such wrong expectations due to confusion about the 279 | version number should be minimal. 280 | - While there has certainly been precedent for missing version numbers, this 281 | usually occurs in the context of larger changes to the versioning scheme. 282 | For example, when Java went from 1.4 to 5.0, it's clear that the numbering 283 | system changed. The existing precedent suggests going to PHP 2016 or 284 | something equally distinct, rather than just skipping a version. (No, this 285 | is not a serious suggestion.) 286 | 287 | Vote 288 | ```` 289 | 290 | A 50%+1 (simple majority) vote with two options, “PHP 6” and “PHP 7”, is 291 | proposed. If more votes are for PHP 6, that shall be the name of the next 292 | major release of PHP. Otherwise, if more of votes are for PHP 7, that shall be 293 | its name. 294 | 295 | Decision 296 | ```````` 297 | 298 | - PHP 6: 24 299 | - PHP 7: **58** 300 | 301 | 302 | PHP 7.0 Timeline 303 | ~~~~~~~~~~~~~~~~ 304 | 305 | **From:** https://wiki.php.net/rfc/php7timeline 306 | 307 | Introduction 308 | ```````````` 309 | 310 | With key decisions about both the version number and the engine for PHP 7 311 | behind us, it's time to define an agreed-upon timeline so that all 312 | contributors can align around it. The purpose of this RFC is to define a one 313 | year timeline for the delivery of PHP 7.0, with a projected release date of 314 | November 2015. 315 | 316 | Proposal 317 | ```````` 318 | 319 | As the competitive landscape for PHP is evolving, the proposal is to shorten 320 | that timeline as much as possible while still taking advantage of the unique 321 | opportunities available to us due to the major version number change. A one 322 | year timeline will allow us a fair amount of time to work on changes that are 323 | only allowed in major versions - namely, ones that break compatibility. 324 | Arguably, while we should definitely take the opportunity to implement 325 | compatibility-breaking changes in 7.0, we also shouldn't turn it into a 326 | compatibility-breaking festival, as the more we break, the more likely it is 327 | users would delay upgrades, stay with old, insecure versions - or even 328 | consider other alternative options. RFCs that don't explicitly require a major 329 | version change (i.e., ones that don't break compatibility) - can also be 330 | proposed, but they should be secondary, as they can equally make it into 331 | future minor versions (7.1, 7.2, etc.). 332 | 333 | Proposed Milestones 334 | ################### 335 | 336 | ===================================================== ==================================== ======= 337 | Milestone Timeline Comment 338 | ===================================================== ==================================== ======= 339 | 1. Line up any remaining RFCs that target PHP 7.0. Now - Mar 15 (4+ additional months) We're already well under way with doing that, with the PHPNG, AST, uniform variable syntax, etc. 340 | 2. Finalize implementation & testing of new features. Mar 16 - Jun 15 (3 months) 341 | 3. Release Candidate (RC) cycles Jun 16 - Oct 15 (3 months) Subject to quality! 342 | 4. GA/Release Mid October 2015 Subject to quality! 343 | ===================================================== ==================================== ======= 344 | 345 | It's worth noting that the 3rd and 4th milestones will be quality dependent. 346 | If we have evidence that suggests that PHP 7 isn't sufficiently mature to go 347 | into the RC stage in June, or GA in October - we should of course adjust the 348 | timeline accordingly, and not push out a half-baked release. However, the goal 349 | would be to stick as much as possible to the deadline of new going-into-7.0 350 | RFCs, and strive to follow the timelines for the 2nd and 3rd milestones as 351 | much as possible, to ensure an October 2015 release of PHP 7.0. 352 | 353 | Cleaning Up Unmaintained Extensions (PHP 7.3) 354 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 355 | 356 | Introduction 357 | ```````````` 358 | 359 | We have a number of extensions that have no assigned maintainer. The proposal 360 | is either to find a maintainer for them or move them out of core. The RFC 361 | proposes the procedure for doing this for 7.3 release and repeat it for each 362 | subsequent release. 363 | 364 | Proposal 365 | ```````` 366 | 367 | For the extensions that have no maintainers, the proposal is to: 368 | 369 | - Issue a call for maintainership on internals list (and maybe other venues, 370 | such as thematic PHP communities, as seen appropriate). 371 | - If a maintainer candidate(s) show up: 372 | - If they are already committers, assign them as maintainers. The extension 373 | is considered maintained from now on, no further action needed. 374 | - Otherwise, ask them to submit a couple of patches for existing bugs in the 375 | extension, of their choice. If these are ok, issue them php.net account 376 | with appropriate permissions and assign them as maintainers for the claimed 377 | extension. If extensions has no bugs to fix, assign them as maintainers 378 | immediately (php.net account may not yet be needed). 379 | - If within 3 weeks nobody steps up as a maintainer for extension, it is 380 | considered orphaned. 381 | - All orphaned extensions are converted to PECL modules and removed from core 382 | repository. There should be a public announcement procedure before this 383 | happens, with the details not defined of this RFC but to be worked out by 384 | RMs and the community (either with separate RFC or just by consensus). 385 | - In case there are objections to moving unmaintained extension to PECL, 386 | separate RFC vote can be held about the move, initiated by the RMs of the 387 | current release or any interested party. The decision can be taken for each 388 | extension individually. 389 | 390 | Option: for some extensions, which are clearly needed but nobody stepped up in 391 | person to claim maintainership, we can have designated “community maintained” 392 | status, which would mean PHP developers as a group have shared responsibility 393 | for this extension. This is to be accepted as an inferior solution, which need 394 | to be eventually resolved by either finding a maintainer or finding an 395 | alternative for the extension. 396 | 397 | To be clear, the ideal result of this process is that all core extensions find 398 | a maintainer. So we want to have the process biased towards finding one, not 399 | removing extensions from core. However, if we fail to do so, we rather claim 400 | it explicitly than ship buggy, unmaintained and possibly insecure code to the 401 | users. 402 | 403 | Candidate extensions 404 | ```````````````````` 405 | 406 | These are core extensions for which there is no official maintainer 407 | registered. Please note that the exact content of this list is not part of the 408 | vote - it can change with new maintainers coming up or old maintainers 409 | retiring, and there probably would be a separate list maintained as necessary. 410 | 411 | ============ ======================= =============== ========== ================== 412 | Extension Bugs in DB (minus reqs) Oldest open bug Newest bug Most recent bugfix 413 | ============ ======================= =============== ========== ================== 414 | enchant 4 2008-02-21 2009-10-28 2008-02-23 415 | ftp 26 2010-05-10 2016-06-06 2016-08-16 416 | gettext 6 2007-12-11 2015-09-24 2015-08-31 417 | pdo_odbc 26 2007-06-22 2016-01-18 2009-12-11 418 | readline 4 2012-03-31 2001-01-26 2015-12-11 419 | pspell 2 2014-03-19 2016-04-19 2008-09-16 420 | sysvmsg No bug category 421 | sysvsem 19 2002-04-29 2016-04-04 2014-09-10 422 | sysvshm No bug category 423 | wddx 6 2006-03-17 2016-08-11 2016-08-11 424 | ============ ======================= =============== ========== ================== 425 | 426 | Backward Incompatible Changes 427 | ````````````````````````````` 428 | 429 | Default build of PHP would not have the extensions that will be moved out. 430 | They still could be built from PECL sources. The focus of this RFC, however, 431 | is for establishing procedures for unmaintained extensions rather than dealing 432 | with specific extensions, so decision about each extension can be taken 433 | separately. 434 | 435 | Proposed PHP Version(s) 436 | ``````````````````````` 437 | 438 | The process is proposed for 7.3 and all future PHP versions. 439 | 440 | Future Scope 441 | ```````````` 442 | 443 | We may need to refresh the list of current maintainers (since some maintainers 444 | have moved on) and repeat the process in the future. 445 | 446 | The proposed procedure is to add years to each maintainer's status in the 447 | maintainers list, with the year to be updated manually by the maintainer. If 448 | by end of January of the year the last updated year is past the last year 449 | (e.g., 2018 or less in January 2020), the extension is deemed to be abandoned 450 | by the maintainer. In this case, the maintainer would be asked to clarify the 451 | maintainership status, and absent response or with a negative response, the 452 | extension will be considered having no maintainer. This can be changed at any 453 | moment if the existing or new maintainer comes up (again, the priority is 454 | always towards finding the maintainer, not moving stuff out). 455 | 456 | To initiate this procedure, the years should be initialized with the last 457 | commit or last bug response from the maintainer to the maintained extension 458 | code or bugs. 459 | 460 | 461 | -------------------------------------------------------------------------------- /coding-standards-and-naming.rst: -------------------------------------------------------------------------------- 1 | #################################### 2 | Coding Standards and Naming Policy 3 | #################################### 4 | 5 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 6 | "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this 7 | document are to be interpreted as described in `BCP 14 8 | `_ [`RFC2119 9 | `_] [`RFC8174 10 | `_] when, and only when, they 11 | appear in all capitals, as shown here. 12 | 13 | This policy lists standards that any programmer adding or changing code in PHP 14 | should follow. 15 | 16 | ************** 17 | Symbol Names 18 | ************** 19 | 20 | Acronyms 21 | ======== 22 | 23 | Abbreviations and acronyms as well as initialisms SHOULD be avoided wherever 24 | possible. 25 | 26 | Abbreviations, acronyms, and initialisms MUST be treated like regular words, 27 | thus they should be written with an uppercase first character, followed by 28 | lowercase characters. 29 | 30 | Diverging from this policy is NOT RECOMMENDED, but it is allowed to keep 31 | internal consistency within a single extension, if the name follows an 32 | established, language-agnostic standard, or for other reasons, if those reasons 33 | are properly justified and voted on as part of the RFC process. 34 | 35 | Functions 36 | ========= 37 | 38 | Function names MUST be in lowercase, with words underscore delimited, with care 39 | taken to minimize the letter count. 40 | 41 | Good function names: 42 | 43 | - ``str_word_count`` 44 | - ``array_key_exists`` 45 | 46 | Bad function names: 47 | 48 | - ``hw_GetObjectByQueryCollObj`` 49 | - ``pg_setclientencoding`` 50 | - ``jf_n_s_i`` 51 | 52 | If functions are part of a "parent set" of functions, that parent MUST be 53 | included in the user function name, and should be clearly related to the parent 54 | program or function family. This should be in the form of ``parent_*``: 55 | 56 | A family of ``foo`` functions, for example: 57 | 58 | Good names: 59 | 60 | - ``foo_select_bar`` 61 | - ``foo_insert_baz`` 62 | - ``foo_delete_baz`` 63 | 64 | Bad names: 65 | 66 | - ``fooselect_bar`` 67 | - ``fooinsertbaz`` 68 | - ``delete_foo_baz`` 69 | 70 | Methods 71 | ======= 72 | 73 | Method names SHOULD follow the studlyCaps (also referred to as bumpy case or 74 | camel caps) naming convention, with care taken to minimize the letter count. The 75 | initial letter of the name is lowercase, and each letter that starts a new word 76 | is capitalized. 77 | 78 | Good method names: 79 | 80 | - ``connect()`` 81 | - ``getData()`` 82 | - ``buildSomeWidget()`` 83 | - ``performHttpRequest()`` 84 | 85 | Bad method names: 86 | 87 | - ``get_Data()`` 88 | - ``buildsomewidget()`` 89 | - ``getI()`` 90 | - ``performHTTPRequest()`` 91 | 92 | Classes 93 | ======= 94 | 95 | Existing user-level class names are NOT RECOMMENDED to be changed. Although it 96 | would be possible (class names are case-insensitive). 97 | 98 | New class names MUST be descriptive nouns in PascalCase and as short as 99 | possible. Each word in the class name MUST start with a capital letter, without 100 | underscore delimiters. The class name MUST be prefixed with the name of the 101 | "parent set" (e.g. the name of the extension) if no namespaces are used. 102 | 103 | Good class names: 104 | 105 | - ``Curl`` 106 | - ``CurlResponse`` 107 | - ``HttpStatusCode`` 108 | - ``Url`` 109 | - ``BtreeMap`` (B-tree Map) 110 | - ``UserId`` (User Identifier) 111 | - ``Char`` (Character) 112 | - ``Intl`` (Internationalization) 113 | - ``Ssl\Certificate`` 114 | - ``Ssl\Crl`` (Certificate Revocation List) 115 | - ``Ssl\CrlUrl`` 116 | 117 | Bad class names: 118 | 119 | - ``curl`` 120 | - ``curl_response`` 121 | - ``HTTPStatusCode`` 122 | - ``URL`` 123 | - ``BTreeMap`` 124 | - ``UserID`` (User Identifier) 125 | - ``CHAR`` 126 | - ``INTL`` 127 | - ``SSL\Certificate`` 128 | - ``SSL\CRL`` 129 | - ``SSL\CRLURL`` 130 | 131 | ************ 132 | Namespaces 133 | ************ 134 | 135 | PHP Extension Classification 136 | ============================ 137 | 138 | All symbols (classes, functions, constants) provided by PHP are part of an 139 | extension. Extensions can be classified into three categories: 140 | 141 | - Required extensions (including ``Core`` and ``standard``). These extensions 142 | are always present, and PHP cannot be built without them. 143 | 144 | - Bundled extensions (including ``ctype`` and ``mbstring``). These extensions 145 | are part of the php-src distribution, but PHP can be built without them. 146 | Bundled extensions can be either enabled or disabled by default. 147 | 148 | - 3rd-party extensions (including ``apcu`` and ``igbinary``). These extensions 149 | are not part of the php-src distribution, and either available through PECL, 150 | or on GitHub. 151 | 152 | Extensions may move between these three categories over time. ``hash`` and 153 | ``json`` moved from "bundled" to "required", in PHP 7.4 and 8.0 respectively. 154 | ``sodium`` and ``ffi`` moved from 3rd-party to bundled. ``xmlrpc`` and ``wddx`` 155 | moved from bundled to 3rd-party. 156 | 157 | Core, Standard, Spl 158 | =================== 159 | 160 | Symbols MUST NOT be namespaced under the ``Core``, ``Standard`` or ``Spl`` 161 | namespaces. Instead, these extensions should be considered as a collection of 162 | different components (``str_*``, ``password_*``), and SHOULD be namespaced 163 | according to these component names. 164 | 165 | If a component gets introduced it MAY use a namespace. For example, if a new 166 | component ``vector`` is introduced, it MUST consist of functions all starting 167 | with ``vector_*`` (such as ``vector_multiply()``), OR they MUST all be 168 | namespaced functions under the ``Vector`` namespace, such as 169 | ``Vector\multiply()``. 170 | 171 | Bundled Extensions 172 | ================== 173 | 174 | Bundled PHP extensions SHOULD use namespaces, subject to the guidelines laid out 175 | in the following: 176 | 177 | - Extensions MUST NOT use a vendor namespace. 178 | - The top-level namespace MUST match the extension name (apart from casing). 179 | - Namespace names MUST follow ``CamelCase``. 180 | - All symbols defined in the extension SHOULD be part of the extension's 181 | top-level namespace or a sub-namespace. 182 | 183 | This policy allows the use of namespaces, and provides basic guidelines for 184 | their use. It does not propose to migrate already existing non-namespaced 185 | symbols to use namespaces. 186 | 187 | Examples 188 | -------- 189 | 190 | If we were to introduce ``openssl`` as a new namespaced extension, here is how 191 | the symbol names could change in line with these guidelines: 192 | 193 | - ``OpenSSLCertificate`` becomes ``Openssl\Certificate`` 194 | - ``openssl_dh_compute_key()`` becomes ``Openssl\dh_compute_key()`` 195 | - ``X509_PURPOSE_SSL_CLIENT`` becomes ``Openssl\X509_PURPOSE_SSL_CLIENT`` 196 | 197 | The above guidelines recommend against the global ``FFI`` class used by the 198 | ``ffi`` extension. Using ``Ffi\Ffi`` would be preferred. 199 | 200 | Existing Non-Namespaced Symbols and Consistency 201 | =============================================== 202 | 203 | When adding new symbols to existing extensions it is RECOMMENDED to be 204 | consistent with existing symbols, rather than to follow the namespacing 205 | guidelines. 206 | 207 | For example, the ``array_is_list()`` function added in PHP 8.1 MUST indeed be 208 | called ``array_is_list()`` and MUST NOT have been introduced as 209 | ``Array\is_list()`` or similar. Unless and until existing ``array_*()`` 210 | functions are aliased under an ``Array\*`` namespace, new additions MUST 211 | continue to be of the form ``array_*()`` to maintain horizontal consistency. 212 | 213 | This is a somewhat loose guideline, and applies more strongly to functions than 214 | classes. In particular, when new object-oriented elements are introduced into an 215 | extension that has historically been procedural, these MAY be namespaced. For 216 | example, if ``OpenSSLCertificate`` had only been introduced in PHP 8.1, it could 217 | have been named ``Openssl\Certificate``. 218 | 219 | For the Core, Standard, and Spl extensions, the previous considerations on 220 | component subdivision apply. The fact that string and array functions are not 221 | namespaced does not preclude new namespaced components in these extensions. 222 | 223 | Namespace Collisions 224 | ==================== 225 | 226 | As a matter of courtesy, top-level namespaces used by extensions SHOULD avoid 227 | collisions with existing, commonly used open-source libraries or extensions (or 228 | happen with the agreement of the parties involved). This document does not try 229 | to provide a hard guideline on what constitutes a sufficiently important 230 | library. The application of common sense is recommended. 231 | 232 | Throwables 233 | ========== 234 | 235 | Newly introduced extensions MUST follow the following rules, existing extensions 236 | SHOULD follow the rules for newly introduced exceptions, but MAY diverge for 237 | consistency with existing symbols. 238 | 239 | In the interest of readability the following text uses the word "exception" to 240 | refer to any kind of ``Throwable``. ``Exception`` in code blocks refers to the 241 | ``\Exception`` class. 242 | 243 | The class name of an exception MUST end in ``Exception`` (when extending from 244 | the ``Exception`` hierarchy) or ``Error`` (for the ``Error`` hierarchy). 245 | Exceptions MUST NOT be ``final``. 246 | 247 | Extensions MUST have their own hierarchy of exceptions. At the lowest level of 248 | the hierarchy there MUST be a base ``Exception`` and base ``Error`` defined 249 | within the top-level of the extension's namespace. The unqualified class name of 250 | the base exceptions must be the name of the extension followed by ``Exception`` 251 | or ``Error``. These base exceptions MUST directly extend from the global base 252 | ``\Exception`` or ``\Error`` classes. The extension's base ``Error`` MAY be 253 | omitted if it is unused. 254 | 255 | As an example, an extension called ``Example`` would define the following base 256 | exceptions: 257 | 258 | .. code:: 259 | 260 | namespace Example; 261 | 262 | class ExampleException extends \Exception { } 263 | class ExampleError extends \Error { } 264 | 265 | An extension SHOULD define additional exceptions as appropriate to allow users 266 | to catch specific classes of exception for granular error handling. Any 267 | additional exception MUST either extend the extension's base exception or 268 | another exception defined by the extension. The unqualified class name of 269 | additional exceptions SHOULD be sufficiently specific to make collisions with 270 | the unqualified class name of other exceptions unlikely. The name of the 271 | extension SHOULD NOT be used within the unqualified class name of additional 272 | exceptions if the only purpose is to make the class name more unique. 273 | Specifically, the name of the extension SHOULD NOT be a simple prefix or suffix 274 | of the unqualified class name. 275 | 276 | As an example, an additional exception for failing HTTP requests of the curl 277 | extension might be called ``Curl\FailedHttpRequestException``. This is 278 | sufficiently specific to avoid collisions, since using two different HTTP 279 | clients in a single source file is unlikely. It should not use 280 | ``Curl\CurlFailedHttpRequestException``, 281 | ``Curl\FailedCurlHttpRequestException``, 282 | ``Curl\FailedHttpRequestCurlException``, or similar. A file extension however 283 | might want to define a ``File\FileNotFoundException`` and a 284 | ``File\DirectoryNotFoundException``. In this case the name of the extension is a 285 | generic term and the ``File`` prefix in ``FileNotFoundException`` adds useful 286 | context to differentiate it from the ``DirectoryNotFoundException``. 287 | 288 | An extension MUST NOT throw exceptions that it did not define itself, except for 289 | the global ``TypeError`` or ``ValueError`` exceptions thrown during parameter 290 | parsing and parameter validation, and (subclasses of) exceptions that are 291 | already defined to be thrown by a class that is subclassed itself. If an 292 | extension uses external functionality that may throw an exception it MUST wrap 293 | any exception thrown by that functionality into an appropriate exception of its 294 | own. It MUST set the ``$previous`` property to the original exception when doing 295 | so. 296 | 297 | As an example, an extension that uses the CSPRNG must wrap the 298 | ``Random\RandomException`` thrown on CSPRNG failure into an appropriate 299 | extension-specific exception. 300 | 301 | The ``Error`` hierarchy MUST NOT be used for errors that are expected to be 302 | thrown (and caught) during normal operation of a PHP program. 303 | 304 | As an example, a parsing function that is expected to be used with untrusted 305 | input must not throw an ``Error`` if the input is malformed. Similarly a 306 | function that interacts with the network must not throw an ``Error`` if the 307 | network operation fails. Any ``Error`` that is thrown should usually result in a 308 | reasonably obvious fix in the PHP program. 309 | 310 | All exceptions MUST have a descriptive exception message intended for human 311 | consumption. Non-base exceptions MAY define additional properties to provide 312 | additional metadata about the nature of the error. 313 | 314 | The exception message MUST NOT be the only means of distinguishing exception 315 | causes that the user might want to handle differently. Any two exceptions with 316 | different causes MUST be identifiable either by a unique exception class name, a 317 | stable ``$code``, or a class-specific additional property suitable for 318 | programmatic consumption (e.g. an enum). 319 | 320 | As an example, in an HTTP client a connection failure due to a timeout is 321 | considered to be a different cause than a connection failure due to a 322 | non-existent hostname, as the user might want to schedule a retry when the 323 | connection times out, but not for unknown hostnames. If using the same 324 | ``ConnectionFailureException`` class name for both errors, they must provide a 325 | property suitable for programmatic consumption and may not just differ in their 326 | exception message. 327 | 328 | ************************ 329 | Implementation Details 330 | ************************ 331 | 332 | #. Document your code in source files and the manual. (tm) 333 | 334 | #. PHP is implemented in C11. 335 | 336 | For instance, the optional fixed-width integers from ``stdint.h`` 337 | (``int8_t``, ``int16_t``, ``int32_t``, ``int64_t`` and their unsigned 338 | counterparts) are supposed to be available. 339 | 340 | #. Functions that are given pointers to resources SHOULD NOT free them, unless 341 | this is documented. 342 | 343 | For instance, ``function int mail(char *to, char *from)`` should NOT free 344 | ``to`` and/or ``from``. 345 | 346 | Exceptions: 347 | 348 | - The function's designated behavior is freeing that resource. E.g. 349 | ``efree()``. 350 | 351 | - The function is given a boolean argument, that controls whether or not the 352 | function may free its arguments (if ``true``, the function must free its 353 | arguments; if ``false``, it must not). 354 | 355 | - Low-level parser routines, that are tightly integrated with the token 356 | cache and the bison code for minimum memory copying overhead. 357 | 358 | #. Functions that are tightly integrated with other functions within the same 359 | module, and rely on each other's non-trivial behavior, MUST be documented as 360 | such and declared ``static``. 361 | 362 | #. You SHOULD use definitions and macros whenever possible, so that constants 363 | have meaningful names and can be easily manipulated. Any use of a numeric 364 | constant to specify different behavior or actions SHOULD be done through a 365 | ``#define``. 366 | 367 | #. When writing functions that deal with strings, you SHOULD use 368 | ``zend_string``, which holds the value and the length property of each 369 | string. 370 | 371 | Write your functions in such a way so that they'll take advantage of the 372 | length property by using ``ZSTR_LEN()``, both for efficiency, and in order 373 | for them to be binary-safe. 374 | 375 | #. You SHOULD use the ``smart_str_*`` family of functions for string creation, 376 | instead of relying on the C-library versions, such as ``strncat()``. 377 | 378 | #. You SHOULD use ``PHP_*`` macros in the PHP source, and ``ZEND_*`` macros in 379 | the Zend part of the source. Although the ``PHP_*`` macros are mostly aliased 380 | to the ``ZEND_*`` macros it gives a better understanding on what kind of 381 | macro you're calling. 382 | 383 | #. You MUST NOT define functions that are not available. For instance, if a 384 | library is missing a function, do not define the PHP version of the function, 385 | and do not raise a run-time error about the function not existing. End users 386 | should use ``function_exists()`` to test for the existence of a function. 387 | 388 | #. You SHOULD use ``emalloc()``, ``efree()``, ``estrdup()``, instead of their 389 | standard C library counterparts. These functions implement an internal 390 | "safety-net" mechanism that ensures the deallocation of any unfreed memory at 391 | the end of a request. They also provide useful allocation and overflow 392 | information while running in debug mode. 393 | 394 | In almost all cases, memory returned to the engine must be allocated using 395 | ``emalloc()``. 396 | 397 | The use of ``malloc()`` SHOULD be limited to cases where a third-party 398 | library may need to control or free the memory, or when the memory in 399 | question needs to survive between multiple requests. 400 | 401 | #. The return type of "is" or "has" style functions SHOULD be ``bool`` which 402 | return a "yes"/"no" answer. `zend_result` is an appropriate return value for 403 | functions that perform some operation that may succeed or fail. 404 | 405 | Variable Names 406 | ============== 407 | 408 | Variable names MUST be meaningful. One letter variable names SHOULD be avoided, 409 | except for places where the variable has no real meaning or a trivial meaning 410 | (e.g. ``for (i=0; i<100; i++) ...``). 411 | 412 | Variable names MUST be in lowercase. Use underscores to separate between words. 413 | 414 | Internal Function Naming Conventions 415 | ==================================== 416 | 417 | The main module source file MUST be named ``modulename.c``. 418 | 419 | Header files that are used by other sources must be named ``php_modulename.h``. 420 | 421 | Functions that are part of the external API MUST be named 422 | ``php_modulename_function()`` to avoid symbol collision. They MUST be in 423 | lowercase, with words underscore delimited. Exposed API MUST be defined in 424 | ``php_modulename.h``: 425 | 426 | .. code:: 427 | 428 | PHPAPI char *php_session_create_id(PS_CREATE_SID_ARGS); 429 | 430 | Unexposed module function MUST be ``static`` and MUST NOT be defined in 431 | `php_modulename.h`: 432 | 433 | .. code:: 434 | 435 | static int php_session_destroy() 436 | 437 | Syntax and indentation 438 | ====================== 439 | 440 | You SHOULD Use K&R-style. When you write code that goes into the core of PHP or 441 | one of its standard modules, please maintain the K&R style. 442 | 443 | Be generous with whitespace and braces. Keep one empty line between the variable 444 | declaration section and the statements in a block, as well as between logical 445 | statement groups in a block. Maintain at least one empty line between two 446 | functions. Always prefer: 447 | 448 | .. code:: 449 | 450 | if (foo) { 451 | bar; 452 | } 453 | 454 | to: 455 | 456 | .. code:: 457 | 458 | if(foo)bar; 459 | 460 | You MUST use the tab character when indenting. A tab is expected to represent 461 | four spaces. It is important to maintain consistency in indentation so that 462 | definitions, comments, and control structures line up correctly. 463 | 464 | Preprocessor statements (``#if`` and such) MUST start at column one. To indent 465 | preprocessor directives you should put the ``#`` at the beginning of a line, 466 | followed by any number of spaces. 467 | 468 | The length of constant string literals SHOULD be calculated via ``strlen()`` 469 | instead of using ``sizeof()-1`` as it is clearer and any modern compiler will 470 | optimize it away. Legacy usages of the latter style exists within the codebase 471 | but SHOULD NOT be refactored, unless larger refactoring around that code is 472 | taking place. 473 | 474 | Testing 475 | ======= 476 | 477 | Extensions SHOULD be well tested using ``*.phpt`` tests. Read more at 478 | `qa.php.net documentation `_. 479 | 480 | Experimental Functions 481 | ====================== 482 | 483 | New extensions MUST start out as third-party extensions, or in an experimental 484 | branch, until an RFC is passed to add them to the core distribution. 485 | 486 | Aliases & Legacy Documentation 487 | ============================== 488 | 489 | You may also have some deprecated aliases with close to duplicate names, for 490 | example, ``somedb_select_result`` and ``somedb_selectresult``. For documentation 491 | purposes, these will only be documented by the most current name, with the 492 | aliases listed in the documentation for the parent function. For ease of 493 | reference, user-functions with completely different names, that alias to the 494 | same function (such as ``highlight_file`` and ``show_source``), will be 495 | separately documented. 496 | 497 | Backwards compatible functions and names SHOULD be maintained as long as the 498 | code can be reasonably be kept as part of the codebase. See the `README in the 499 | PHP documentation repository 500 | `_ for more information 501 | on documentation. 502 | 503 | ************** 504 | Related RFCs 505 | ************** 506 | 507 | - From: `Class Naming RFC `_ 508 | - From: `Casing of acronyms in class and method names RFC 509 | `_ 510 | - From `Namespaces in Bundled Extensions RFC 511 | `_. 512 | -------------------------------------------------------------------------------- /feature-proposals.rst: -------------------------------------------------------------------------------- 1 | ################### 2 | Feature Proposals 3 | ################### 4 | 5 | ************** 6 | Introduction 7 | ************** 8 | 9 | This document describes the procedure to propose an idea for adoption by the PHP 10 | community and decide if the community accepts or rejects the idea. 11 | 12 | ********************* 13 | Proposal Initiation 14 | ********************* 15 | 16 | Proposal is formally initiated by creating an RFC on PHP wiki and announcing it 17 | on the list. If the proposal is a repeated discussion of an existing RFC, with 18 | or without modification, it still should be announced on the list for 19 | discussion. 20 | 21 | The announcement will be done in a way that's easy to flag & follow, e.g. - by 22 | ``[RFC]`` in the subject line followed by the title of the RFC. 23 | 24 | The proposal should be initiated by one of its authors. If the proposal is a 25 | repeated one, re-proposed by somebody else, the proposer should discuss it with 26 | the original author, if possible, and add himself to the RFC author list before 27 | proposing it. 28 | 29 | If the proposer is not a member of php.net and thus can not create RFCs on the 30 | wiki, they should recruit one of the members for help or request membership. 31 | 32 | ******************* 33 | Discussion Period 34 | ******************* 35 | 36 | There'd be a minimum of 2 weeks between when an RFC that touches the language is 37 | brought up on this list and when it's voted on is required. Other RFCs might use 38 | a smaller timeframe, but it should be at least a week. The effective date will 39 | not be when the RFC was published on the PHP wiki - but when it was announced on 40 | ``internals@lists.php.net``, by the author, with the intention of voting on it. 41 | This period can be extended when circumstances warrant it - such as major 42 | conferences, key people being busy, force major events, or when discussion 43 | merits it - but should never be less than minimal time. 44 | 45 | This does not preclude discussion on the merits on any idea or proposal on the 46 | list without formally submitting it as a proposal, but the discussion time is 47 | measured only since the formal discussion announcement as described above. 48 | 49 | ******** 50 | Voting 51 | ******** 52 | 53 | The author decides when it's time to move ahead and call a vote on the RFC. If 54 | the author feels that there's still healthy discussion going on, they can decide 55 | not to move ahead to request a vote after the minimal period, but extend it as 56 | needed. On the other hand, if they feel that the discussion is being derailed - 57 | they can always move ahead to a vote as long as the minimum discussion time 58 | elapsed. 59 | 60 | The vote is announced on the mailing list in a separate thread by sending an 61 | email with the subject ``[VOTE]``. It should reference the RFCs being voted on 62 | and if there are different options discussed, explain these options. It should 63 | also contain the URL of the page where the vote is taking place. 64 | 65 | Votes should be open for two weeks at minimum, at the authors discretion this 66 | may be extended, for example during holiday periods. 67 | 68 | A valid voting period must be declared when voting is started and must not be 69 | changed during the vote. 70 | 71 | This section has been amended by: 72 | 73 | - `Abolish Short Votes RFC `_. 74 | 75 | ******************* 76 | Required Majority 77 | ******************* 78 | 79 | The primary vote of an RFC, determining overall acceptance of the proposal, may 80 | only have two voting options and requires a 2/3 majority. This means that the 81 | number of Yes votes must be greater than or equal to the number of No votes 82 | multiplied by two. 83 | 84 | Additionally, an RFC may have secondary votes, which are used to decide 85 | implementation details. Such votes may have more than two voting options and may 86 | be decided by simple plurality. This means that the voting option with the most 87 | votes wins. If there are multiple options with the most number of votes, it is 88 | left at the discretion of the RFC author to choose one of them. 89 | 90 | For procedural reasons, multiple RFCs may be combined into one, in which case 91 | there may be multiple primary votes. Combining multiple RFCs into one does not 92 | allow turning a primary vote into a secondary vote. 93 | 94 | This section has been amended by: 95 | 96 | - `Abolish Narrow Margins RFC 97 | `_. 98 | 99 | ********************************* 100 | Resurrecting Rejected Proposals 101 | ********************************* 102 | 103 | In order to save valuable time, it will not be allowed to bring up a rejected 104 | proposal up for another vote, unless one of the following happens: 105 | 106 | - 6 months pass from the time of the previous vote, **OR** 107 | 108 | - The author(s) make substantial changes to the proposal. While it's impossible 109 | to put clear definitions on what constitutes 'substantial' changes, they 110 | should be material enough so that they'll significantly affect the outcome of 111 | another vote. 112 | 113 | ************** 114 | Who Can Vote 115 | ************** 116 | 117 | There's no way around this 'small' issue. Changes made to the PHP language will 118 | affect millions of people, and theoretically, each and every one of them should 119 | have a say in what we do. For obvious reasons, though, this isn't a practical 120 | approach. 121 | 122 | The proposal here is for two audiences to participate in the voting process: 123 | 124 | - People with php.net VCS accounts that have contributed code to PHP 125 | 126 | - Representatives from the PHP community, that will be chosen by those with 127 | php.net VCS accounts 128 | 129 | - Lead developers of PHP based projects (frameworks, cms, tools, etc.) 130 | - regular participant of internals discussions 131 | 132 | ************** 133 | RFC Proposer 134 | ************** 135 | 136 | - Proposers vote with +1 on their own RFC per default if they are allowed to 137 | vote 138 | -------------------------------------------------------------------------------- /release-process.rst: -------------------------------------------------------------------------------- 1 | ################# 2 | Release Process 3 | ################# 4 | 5 | .. contents:: 6 | :depth: 2 7 | 8 | :From: 9 | https://wiki.php.net/rfc/releaseprocess 10 | 11 | :Updated by: 12 | https://wiki.php.net/rfc/release_cycle_update 13 | 14 | This document outlines the release cycles of the PHP language. 15 | 16 | *************** 17 | Release Cycle 18 | *************** 19 | 20 | Roughly: 21 | 22 | - Yearly release cycle 23 | 24 | - 4 years release life cycle 25 | 26 | - 2 years bug fixes only 27 | - 2 years security fixes only 28 | 29 | No feature addition after final x.y.0 release (or x.0.0). 30 | 31 | Backward compatibility MUST be respected within the same major release (e.g., 32 | 8.x.x). Binary compatibility (API or ABI) MAY be broken between two features 33 | releases, f.e. between 8.3 and 8.4. 34 | 35 | Major Version Number 36 | ==================== 37 | 38 | - x.y.z to x+1.0.0 39 | 40 | - Bug fixes 41 | - New features 42 | - Extensions support can be ended (moved to PECL) 43 | - Backward compatibility can be broken 44 | - API compatibility can be broken (internals and userland) 45 | - ABI can be broken (internals) 46 | 47 | Minor Version Number 48 | ==================== 49 | 50 | - x.y.z to x.y+1.z 51 | 52 | - Bugfixes 53 | - New features 54 | - Extensions support can be ended (moved to PECL) 55 | - Backward compatibility must be kept 56 | - API compatibility must be kept (userland) 57 | - ABI and API can be broken (internals) 58 | - Source compatibility should be kept if possible, while breakages are 59 | allowed 60 | 61 | Patch Version Number 62 | ==================== 63 | 64 | - x.y.z to x.y.z+1 65 | 66 | - Bug fixes and security patches only 67 | - Extensions support can't be removed (like move them to PECL) 68 | - Backward compatibility must be kept (internals and userland) 69 | - ABI and API compatibility must be kept (internals) 70 | 71 | It is critical to understand the consequences of breaking BC, APIs or ABIs (only 72 | internals related). It should not be done for the sake of doing it. RFCs 73 | explaining the reasoning behind a breakage and the consequences along with test 74 | cases and patch(es) should help. 75 | 76 | See the following links for explanation about API and ABI: 77 | 78 | - http://en.wikipedia.org/wiki/Application_programming_interface 79 | - http://en.wikipedia.org/wiki/Application_binary_interface 80 | 81 | Example time line with only one major version at a time 82 | ------------------------------------------------------- 83 | 84 | .. code:: 85 | 86 | **** pre release phase 87 | ++++ release lifetime with all bug fixes, no feature addition 88 | ---- release lifetime security fixes only 89 | G GA Release 90 | D EOL 91 | 92 | Version Time -> 93 | 2023 2024 2025 2026 2027 2028 2029 94 | | | | | | | | | | | | | | 95 | 8.1 |++++++++++-------------------------D 96 | 8.2 |+++++++++++++++++++++++------------------------D 97 | 8.3 | *****G++++++++++++++++++++++++------------------------D 98 | 8.4 | | | |****G++++++++++++++++++++++++------------------------D 99 | 100 | ****************** 101 | Release Timeline 102 | ****************** 103 | 104 | The process starts the first Tuesday of July of each year, and nominally runs 105 | for 20 weeks. With 3 alpha releases, 3 beta releases, 4 release candidates, and 106 | a GA (x.0.0) release. 107 | 108 | Examples are given for 2024 and PHP 8.4. Releases are tagged on the Tuesday of 109 | each week, with a release before Thursday 24:00 (UTC). 110 | 111 | In the examples, `$rd` describes the release day of the first alpha release. 112 | 113 | Alpha Releases 114 | ============== 115 | 116 | .. list-table:: 117 | :header-rows: 0 118 | :stub-columns: 1 119 | 120 | - - Alpha 1 121 | - - Tag on *First Tuesday of July*: ``$rd - 2`` (Jul 2, 2024) 122 | - Release before *First Thursday of July*: ``$rd`` (Jul 4, 2024) 123 | 124 | - - Alpha 2 125 | - ``$rd + 14`` (Jul 18, 2024) 126 | 127 | - - Alpha 3 128 | - ``$rd + 28`` (Aug 01, 2024) 129 | 130 | During the alpha releases: 131 | 132 | - New features may be added at will, following the normal RFC procedures. 133 | 134 | Beta Releases 135 | ============= 136 | 137 | .. list-table:: 138 | :header-rows: 0 139 | :stub-columns: 1 140 | 141 | - - Beta 1 142 | - - Tag / Feature Freeze: ``$rd + 40`` (Aug 13, 2024) 143 | - Release: ``$rd + 42`` (Aug 15, 2024) 144 | 145 | - - Beta 2 146 | - ``$rd + 56`` (Aug 29, 2024) 147 | 148 | - - Beta 3 149 | - ``$rd + 70`` (Sep 12, 2024) 150 | 151 | At feature freeze: 152 | 153 | - All features requiring an RFC must have passed by the voting mechanism, and 154 | SHOULD be merged prior to feature freeze. 155 | 156 | After feature freeze, with blessing of the release managers: 157 | 158 | - Merging features that do require an RFC is still allowed. 159 | - Features that do not require an RFC are still allowed. 160 | - Optimisations and internal ABI and API changes are also still allowed. 161 | 162 | Release Candidates 163 | ================== 164 | 165 | .. list-table:: 166 | :header-rows: 0 167 | :stub-columns: 1 168 | 169 | - - Release Candidate 1 170 | - - Tag: ``$rd + 82`` (Sep 24, 2024) 171 | - Release: ``$rd + 84`` (Sep 26, 2024) 172 | 173 | - - Release Candidate 2 174 | - ``$rd + 98`` (Oct 10, 2024) 175 | 176 | - - Release Candidate 3 177 | - ``$rd + 112`` (Oct 24, 2024) 178 | 179 | - - Release Candidate 4 180 | - ``$rd + 126`` (Nov 07, 2024) 181 | 182 | More release candidates MAY be added on a two-week cycle, if necessary. 183 | 184 | With the first release candidate: 185 | 186 | - Internal API numbers MUST be updated (``PHP_API_VERSION``, 187 | ``ZEND_MODULE_API_NO``, and ``ZEND_EXTENSION_API_NO``). 188 | - The release branch (``PHP-8.4``) MUST be created. 189 | 190 | After the first release candidate: 191 | 192 | - There MUST NOT be any API and ABI changes in subsequent RCs. 193 | - There MUST NOT be any new features, small or otherwise, in subsequent RCs. 194 | 195 | General Availability 196 | ==================== 197 | 198 | .. list-table:: 199 | :header-rows: 0 200 | :stub-columns: 1 201 | 202 | - - x.y.0 (8.4.0) 203 | - - Tag: ``$rd + 138`` (Nov 19, 2024) 204 | - Release: ``$rd + 140`` (Nov 21, 2024) 205 | 206 | The GA release MUST be released from the last Release Candidate tag (RC4 or 207 | later). There MUST NOT be any changes between the last Release Candidate tag and 208 | the GA tag (with exception to files such as `NEWS` and other files where the PHP 209 | version number must change for the GA release). 210 | 211 | Bug Fix and Security Releases 212 | ============================= 213 | 214 | After the general availability release: 215 | 216 | - Until the end of year 2 (e.g., for PHP 8.4: until Dec 31, 2026): 217 | 218 | - A new release every 4 weeks, synchronised with other release branches. 219 | - Bug fixes and security fixes. 220 | 221 | - Until the end of year 3 (e.g., for PHP 8.4: until Dec 31, 2027): 222 | 223 | - Security fixes, and fixes to address regressions introduced during a 224 | normal bug fix release. 225 | 226 | - Updates to ABI incompatible versions of dependent libraries on Windows. 227 | 228 | - Release only when there is a security issue or regression issue to 229 | address. 230 | 231 | - Security fix and regression releases SHOULD occur on the same date as 232 | bug fix releases for the other branches. Exceptions can be made for 233 | high risk security issues or high profile regressions. 234 | 235 | - Until the end of year 4 (e.g., for PHP 8.4: until Dec 31, 2028): 236 | 237 | - Security fixes **only**. 238 | 239 | - Release only when there is a security issue. 240 | 241 | - Security fix releases SHOULD occur on the same date as bug fix releases 242 | for the other branches. Exceptions can be made for high risk security 243 | issues. 244 | 245 | - Updates to ABI incompatible versions of dependent libraries on Windows 246 | are **not** performed. 247 | 248 | *"End of year" means:* The end of the calendar year, i.e., Dec 31 at 24:00 UTC. 249 | The numbered years in the examples (e.g., "end of year 2") indicate the number 250 | of calendar years following the *original planned GA release date*. For example, 251 | if the planned GA release date for PHP 8.4 is Nov 21, 2024, then "end of year 2" 252 | is Dec 31, 2026, 24:00 UTC, even if the actual release date slips to Jan 9, 253 | 2025. 254 | 255 | *********************************** 256 | Feature selection and development 257 | *********************************** 258 | 259 | RFCs have been introduced many years ago and have been proven as being an 260 | amazing way to avoid conflicts while providing a very good way to propose new 261 | things to php.net. New features or additions to the core should go through the 262 | RFC process. It has been done successfully (as the process went well, but the 263 | features were not necessary accepted) already for a dozen of new features or 264 | improvements. 265 | 266 | Features can use branch(es) if necessary, doing so will minimize the impact of 267 | other commits and changes on the development of a specific feature (or the other 268 | way 'round). The shorter release cycle also ensures that a given feature can get 269 | into the next release, as long as the RFC has been accepted. 270 | 271 | The change to what we have now is the voting process. It will not happen anymore 272 | on the mailing list but in the RFCs directly, for php.net members, in a public 273 | way. 274 | 275 | See also `the voting RFC `_. 276 | 277 | The question for this section is about who will be allowed to vote: 278 | 279 | - php-src (yes, no) 280 | - php-doc (yes, no) 281 | - qa, phpt (yes, no) 282 | - other sub projects like pear (yes, no) 283 | 284 | We have voting plugin for dokuwiki (doodle2) that allows voting on the wiki 285 | (installed). 286 | 287 | ********** 288 | RMs Role 289 | ********** 290 | 291 | The roles of the release managers are about being a facilitator: 292 | 293 | - Manage the release process 294 | - Start the decisions discussions and vote about the features and change for a 295 | given release 296 | - Create a roadmap and planing according to this RFC 297 | - Package the releases (test and final releases) 298 | - Decide which bug fixes can be applied to a release, within the cases defined 299 | in this RFC 300 | 301 | But they are not: 302 | 303 | - Decide which features, extension or SAPI get in a release or not 304 | 305 | Discussions or requests for a feature or to apply a given patch must be done on 306 | the public internals mailing list or in the security mailing (ideally using the 307 | bug tracker) 308 | 309 | **************************** 310 | Release managers selection 311 | **************************** 312 | 313 | About three months prior to the scheduled release of the first alpha release of 314 | the next minor or major version (around April 1st or shortly thereafter), the 315 | release managers for the latest version branch should issue a call for 316 | volunteers to begin the selection process for the next release managers. 317 | 318 | The release manager team consists of two or three people, it is notable that at 319 | least one of the volunteers should be a "veteran" release manager, meaning they 320 | have contributed to at least one PHP release in the past. The other can be an 321 | additional veteran or, ideally, someone new to the RM role (to increase number 322 | of veteran RMs). 323 | 324 | Issue the call for volunteers on internals@lists.php.net on or around March 1st. 325 | See, for example: https://news-web.php.net/php.internals/113334 326 | 327 | There is no rule for how long the call for volunteers must remain open. We 328 | should aim to select the release managers by early April, so announcing the call 329 | in early March gives people about a month to decide whether they wish to 330 | volunteer. 331 | 332 | Voting is conducted using "Single Transferrable Vote" (STV). 333 | 334 | Using some maths, we'll start with the 1st preference and gradually remove 335 | candidates with the fewest votes, transferring votes that had previously gone to 336 | them to their voter’s 2nd preference, and so on. Once required number of 337 | candidates have a quorum (Droop quota), those will be officially selected as our 338 | RMs. 339 | 340 | *************************************************************** 341 | Feature(s) preview release, solving the experimental features 342 | *************************************************************** 343 | 344 | Some features require a lot of testing or users feedback before they can be 345 | considered as ready, stable enough, or proven as having made good design 346 | decisions. Having them in normal releases is dangerous. The past releases told 347 | us more than once that many good ideas ended as being not so good after all. But 348 | we had to keep them in and, even worst, maintain them forever. 349 | 350 | A feature preview release could solve this problem. A feature(s) preview release 351 | gives us and our users a way to try bleeding edge additions to the language or 352 | core while providing us with an invaluable feedback to actually valid both the 353 | implementation and the design choices. 354 | 355 | Non core features (engine, stream, etc.) could benefit from a feature preview 356 | release while doing it via PECL should be the preferred way. 357 | 358 | Feature(s) preview releases can happen any time and can be platform specific. 359 | Whether a specific development branch is used or not is up to the developers of 360 | the given features (external repositories like github or bitbucket can obviously 361 | be used as well). 362 | 363 | ********************* 364 | Security Management 365 | ********************* 366 | 367 | - Each security flaw must have a CVE id before the final release. 368 | 369 | - Ideally security issues and their fixes are reported and discussed in the 370 | issues tracker 371 | 372 | - Needs a 'security' flag in bugs.php.net (implemented, a CVE field has been 373 | added as well) 374 | - Methods to reproduce a flaw may remain non public (on a case by case 375 | basis) 376 | - Be sure that the security team of each major distributions have access to 377 | the security reports, before public release 378 | -------------------------------------------------------------------------------- /security-classification.rst: -------------------------------------------------------------------------------- 1 | ################################# 2 | Vulnerability Disclosure Policy 3 | ################################# 4 | 5 | This document was originally published at . 6 | 7 | ************** 8 | Introduction 9 | ************** 10 | 11 | For the sake of our users, we classify some of the issues found in PHP as 12 | "security issues". This document is intended to explain which issues are thus 13 | classified, how we handle those issues and how to report them. 14 | 15 | **************** 16 | Classification 17 | **************** 18 | 19 | We classify as security issues bugs that: 20 | 21 | - allow users to execute unauthorized actions 22 | - cross security boundaries 23 | - access data that is not intended to be accessible 24 | - severely impact accessibility or performance of the system 25 | 26 | The purpose of this classification is to alert the users and the developers 27 | about the bugs that need to be prioritized in their handling. 28 | 29 | We define three categories of security issues, by their severity, described 30 | below. Please note that this categorization is in many aspects subjective, so it 31 | ultimately relies on the judgement of the PHP developers. 32 | 33 | High Severity 34 | ============= 35 | 36 | These issues may allow: 37 | 38 | - third party to compromise any, or most installations of PHP 39 | - the execution of arbitrary code 40 | - disabling the system completely 41 | - access to any file a local PHP user can access. 42 | 43 | The issue can be triggered on any, or on most typical installations, and does 44 | not require exotic and non-recommended settings to be triggered. 45 | 46 | This category also includes issues that can be triggered in code or functions 47 | known to be frequently used (session, json, mysql, openssl, etc.) during typical 48 | usage, and that require settings or configurations that may not be strictly the 49 | best practice, but are commonly used. 50 | 51 | This category also may include issues that require special code or code pattern 52 | if such code or pattern is present in many popular libraries. 53 | 54 | This kind of issues usually requires a CVE report. 55 | 56 | Medium Severity 57 | =============== 58 | 59 | These issues may have the same potential to compromise an installation as a high 60 | severity issue, but may also require: 61 | 62 | - an extension that is not commonly used 63 | - a particular type of configuration that is used only in narrow specific 64 | circumstances 65 | - relies on old version of a third-party library being used 66 | - code, or patterns of code, that are known to be used infrequently 67 | - code that is very old, or extremely uncommon (and so is used infrequently) 68 | 69 | This kind of issues usually will have a CVE number, unless the required 70 | configuration is particularly exotic to the point it's not practically usable. 71 | 72 | Low Severity 73 | ============ 74 | 75 | This issue allows theoretical compromise of security, but practical attack is 76 | usually impossible or extremely hard due to common practices or limitations that 77 | are virtually always present or imposed. 78 | 79 | This also includes problems with configuration, documentation, and other 80 | non-code parts of the PHP project that may mislead users, or cause them to make 81 | their system, or their code less secure. 82 | 83 | Issues that can trigger unauthorized actions that do not seem to be useful for 84 | any practical attack can also be categorized as low severity. 85 | 86 | Security issues, that are present only in unstable branches, belong to this 87 | category, too. Any branch that has no stable release, is per se not intended for 88 | the production use. 89 | 90 | Low severity issues usually do not need to have CVE and may, at the discretion 91 | of the PHP developers, be disclosed publicly before the fix is released or 92 | available. 93 | 94 | Not a Security Issue 95 | ==================== 96 | 97 | We do not classify as a security issue any issue that: 98 | 99 | - requires invocation of specific code, which may be valid but is obviously 100 | malicious 101 | 102 | - requires invocation of functions with specific arguments, which may be valid 103 | but are obviously malicious 104 | 105 | - requires specific actions to be performed on the server, which are not 106 | commonly performed, or are not commonly permissible for the user (uid) 107 | executing PHP 108 | 109 | - requires privileges superior to that of the user (uid) executing PHP 110 | 111 | - requires the use of debugging facilities - ex. xdebug, var_dump 112 | 113 | - requires the use of settings not recommended for production - ex. error 114 | reporting to output 115 | 116 | - requires the use of non-standard environment variables - ex. USE_ZEND_ALLOC 117 | 118 | - requires the use of non-standard builds - ex. obscure embedded platform, not 119 | commonly used compiler 120 | 121 | - requires the use of code or settings known to be insecure 122 | 123 | - requires the use of FFI 124 | 125 | - requires an open_basedir bypass 126 | 127 | ***************** 128 | Handling Issues 129 | ***************** 130 | 131 | High and medium severity fixes are merged into a private security repository, 132 | and then merged to the main repository before the release is tagged. 133 | 134 | Low severity fixes are merged immediately after the fix is available and handled 135 | like all regular bugs are handled consequently. However, release managers may 136 | choose to pull those fixes into the RC branch after the branch is created, and 137 | also backport them into a security-only release branch. 138 | 139 | ***** 140 | FAQ 141 | ***** 142 | 143 | How Do I Report a Security Issue? 144 | ================================= 145 | 146 | Please report security vulnerabilities on GitHub at: 147 | 148 | 149 | If for some reason you cannot use the form at GitHub, or you need to talk to 150 | somebody about a PHP security issue that might not be a bug report, please write 151 | to . 152 | 153 | Vulnerability reports remain private until published. When published, you will 154 | be credited as a contributor, and your contribution will reflect the MITRE 155 | Credit System. 156 | 157 | What Do You Consider a Responsible Disclosure? 158 | ============================================== 159 | 160 | Please report the issue as described above. Please communicate with the 161 | developers about when the fix will be released - usually it's the next monthly 162 | release after the bug was reported. Some issues can take longer. After the fix 163 | is released (releases usually happen on Thursdays) please feel free to disclose 164 | the issue as you see fit. 165 | 166 | What If I Think It's a Security Issue But The Developers Disagree? 167 | ================================================================== 168 | 169 | Please read the above and try to explain to us why it fits the description. 170 | 171 | What If The Developers Still Don't Think It's a Security Issue? 172 | =============================================================== 173 | 174 | We'll have to agree to disagree. 175 | 176 | The Bug I Submitted Was Classified As "Not a Security Issue." You Don't Believe It's Real? 177 | ========================================================================================== 178 | 179 | It has nothing to do with the bug being real or its importance to you. It just 180 | means it does not fit our specific definitions for issues that we will handle in 181 | a special way. We fix a lot of non-security bugs and pull requests are always 182 | welcome. 183 | 184 | But You Classified Bug #424242 As a Security Issue, But Not This One?! 185 | ====================================================================== 186 | 187 | Each bug usually has its aspects, if a short discussion does not yield agreement 188 | we'd rather do more fixing and less arguing. 189 | 190 | Do You Pay Bounties For Security Issues? 191 | ======================================== 192 | 193 | PHP is a volunteer project. We have no money, thus we can't pay bounties. 194 | -------------------------------------------------------------------------------- /security-policies.rst: -------------------------------------------------------------------------------- 1 | ############################### 2 | Security Policies and Process 3 | ############################### 4 | 5 | .. IMPORTANT:: 6 | 7 | This is a meta document discussing PHP security policies and processes. For 8 | the actual PHP security policy, see the PHP `Vulnerability Disclosure Policy 9 | `_ 10 | document. 11 | 12 | *************************** 13 | PHP.net security.txt file 14 | *************************** 15 | 16 | PHP.net includes a `security.txt 17 | `_ file that complements the 18 | `Vulnerability Disclosure Policy 19 | `_, 20 | aiding security vulnerability disclosure. This file implements the standard 21 | defined in `RFC 9116 `_, and more 22 | information is available at . 23 | 24 | RFC 9116 requires an ``Expires`` field in ``security.txt``, and its 25 | recommendation is for the ``Expires`` field to be less than a year in the 26 | future. This provides security researchers with confidence they are using our 27 | most up-to-date reporting policies. To facilitate yearly updates to the 28 | ``Expires`` field and ensure freshness of the information in ``security.txt``, 29 | the PHP release managers `update the Expires field as part of the X.Y.0 GA 30 | release 31 | `_. 32 | 33 | From time-to-time, we may update ``security.txt`` with new information, outside 34 | of the yearly changes to the ``Expires`` field. 35 | 36 | Making changes to security.txt 37 | ============================== 38 | 39 | All changes to ``security.txt`` must be signed by a PHP release manager for a 40 | `currently supported version of PHP 41 | `_ (at the time of the changes). 42 | Release managers are the most logical choice for signing this file, since we 43 | already `publish their PGP keys `_. 44 | 45 | To make changes to ``security.txt``: 46 | 47 | #. Go to your local clone of `web-php `_: 48 | 49 | .. code:: 50 | 51 | cd /path/to/web-php/.well-known 52 | 53 | #. Remove the PGP signature that wraps the body of ``security.txt``: 54 | 55 | .. code:: 56 | 57 | gpg --decrypt --output security.txt security.txt 58 | 59 | .. NOTE:: 60 | 61 | To "decrypt" ``security.txt``, you will need the public key of the release 62 | manager who last signed it in your GPG keychain. 63 | 64 | #. Make and save your changes to this file, e.g., update the ``Expires`` 65 | timestamp. 66 | 67 | There should be a "Signed by" comment in the file that looks similar to this: 68 | 69 | .. code:: 70 | 71 | # Signed by Ben Ramsey on 2023-09-28. 72 | 73 | Update this line with your name, the email address associated with the key 74 | you're using to sign the file, and the current date. 75 | 76 | #. Sign your changes: 77 | 78 | .. code:: 79 | 80 | gpg --clearsign --local-user YOU@php.net --output security.txt.asc security.txt 81 | 82 | .. WARNING:: 83 | 84 | You cannot use ``--output`` to output the signature to the same file as 85 | the input file or ``gpg`` will result in a signature wrapped around empty 86 | content. 87 | 88 | #. Last, replace ``security.txt`` with ``security.txt.asc`` and commit your 89 | changes: 90 | 91 | .. code:: 92 | 93 | mv security.txt.asc security.txt 94 | git commit security.txt 95 | 96 | .. NOTE:: 97 | 98 | You may verify the signature with the following command: 99 | 100 | .. code:: 101 | 102 | gpg --verify security.txt 103 | -------------------------------------------------------------------------------- /third-party-code.rst: -------------------------------------------------------------------------------- 1 | ######################## 2 | Third Party Code Usage 3 | ######################## 4 | 5 | ************** 6 | Introduction 7 | ************** 8 | 9 | The PHP project may leverage code written by others, of which the PHP ecosystem 10 | has an ample supply. However, it also wants to avoid giving the appearance of 11 | endorsing or recommending any particular tool over other equally-capable 12 | competitors, even if unintentionally. This document provides a heuristic and 13 | process for addressing that balance. 14 | 15 | ************* 16 | Definitions 17 | ************* 18 | 19 | **PHP tooling** 20 | Refers to the code behind the PHP.net website, the documentation generator 21 | project PhD, the PHP wiki, and other similar systems. In general, “PHP code 22 | run by PHP.net.” 23 | 24 | **Documentation** 25 | Refers to objective information about PHP, the PHP language, the PHP standard 26 | library, and PHP ecosystem hosted on PHP.net. This may include reference 27 | material, tutorials, FAQs, and similar. 28 | 29 | **Marketing material** 30 | Refers to content on PHP.net or similar sites intended to promote or 31 | evangelize PHP the language or ecosystem. 32 | 33 | **Libraries** 34 | Refers to existing third party code packages or tools, either C extensions or 35 | PHP code, maintained by someone other than the PHP Internals team. It also 36 | includes command line utilities used primarily by a developer. It may also 37 | refer to non-profit PHP ecosystem organizations, such as the PHP Foundation 38 | or PHP-FIG. 39 | 40 | **Web Application** 41 | Refers to a “full” web framework that provides end-to-end web application 42 | capabilities, or an installable complete application. It does not refer to 43 | command line utilities used primarily by developers building applications. 44 | 45 | **Approved license** 46 | Refers to a license `approved by the Free Software Foundation as Free 47 | Software `_, and that is 48 | inbound compatible with GPLv3. 49 | 50 | ********************* 51 | Approval Heuristics 52 | ********************* 53 | 54 | PHP Tooling 55 | =========== 56 | 57 | PHP tooling MAY make use of third party libraries, provided that the library 58 | meets all of the “Inclusion” criteria, and does not meet any of the “Exclusion” 59 | criteria. 60 | 61 | Inclusion criteria 62 | ------------------ 63 | 64 | #. The library must have a stable >= 1.0 release, and have had one for at least 65 | a year. (This is to ensure it has longevity.) 66 | #. The library provides targeted, necessary functionality. 67 | #. The library is a recognized de facto standard, or one of a small number of de 68 | facto standards, in its problem space. 69 | #. The library is available under an Approved License. 70 | 71 | Exclusion criteria 72 | ------------------ 73 | 74 | #. The library is a Web Application 75 | #. The library is not available under an Approved License. 76 | #. The library has shown no meaningful activity for one year prior to its first 77 | inclusion. 78 | 79 | PHP tooling maintainers MAY use their judgement to determine if a library meets 80 | the above criteria, but SHOULD be conservative in their interpretation of 81 | whether or not a library satisfies the necessary criteria. 82 | 83 | Explicitly approved libraries 84 | ----------------------------- 85 | 86 | The following libraries have been explicitly approved by RFC vote. 87 | 88 | - Composer 89 | - Xdebug 90 | - phpunit/phpunit 91 | - phpstan/phpstan 92 | - vimeo/psalm 93 | - michelf/php-markdown 94 | - phpmailer/phpmailer 95 | - squizlabs/php_codesniffer 96 | - friendsofphp/php-cs-fixer 97 | - symfony/dotenv 98 | - symfony/console 99 | - fzaninotto/faker 100 | - erusev/parsedown 101 | - amenadiel/jpgraph 102 | - Any library or PSR published by the PHP-FIG 103 | 104 | Explicitly rejected libraries 105 | ----------------------------- 106 | 107 | None 108 | 109 | PHP Documentation 110 | ================= 111 | 112 | Documentation MAY reference and link to third party libraries, provided that the 113 | library meets all of the “Inclusion” criteria, and does not meet any of the 114 | “Exclusion” criteria. Additionally, the language used to refer to the library 115 | must also follow the criteria below. 116 | 117 | Inclusion criteria 118 | ------------------ 119 | 120 | #. The library must have a stable >= 1.0 release, and have had one for at least 121 | a year. 122 | 123 | #. The library provides a use that is commonly needed by many types of projects, 124 | making it of broad interest to the PHP ecosystem. 125 | 126 | #. The library is a recognized de facto standard, or one of a small number of de 127 | facto standards, in its problem space. If there are a small number of de 128 | facto standard libraries, then all should be listed and given equal weight. 129 | 130 | #. The library is available under an Approved License. 131 | 132 | #. The language used to describe the library does not imply that the PHP Project 133 | is involved in or specifically recommends the library over some other. 134 | 135 | Exclusion criteria 136 | ------------------ 137 | 138 | #. The library is one of many (more than ~4) viable options in its problem 139 | space, even if it is the most common of those many options. 140 | #. The library is a Web Application. 141 | #. The library is not available under an Approved License. 142 | #. The library has shown no meaningful activity for one year prior to its first 143 | mention. 144 | #. The library is not of broad interest to the PHP ecosystem. 145 | 146 | PHP tooling maintainers MAY use their judgement to determine if a library meets 147 | the above criteria, but SHOULD be conservative in their interpretation of 148 | whether or not a library satisfies the necessary criteria. 149 | 150 | Explicitly approved libraries 151 | ----------------------------- 152 | 153 | The following libraries have been explicitly approved by RFC vote. 154 | 155 | - Composer 156 | - Xdebug 157 | - phpunit/phpunit 158 | - phpstan/phpstan 159 | - vimeo/psalm 160 | - squizlabs/php_codesniffer 161 | - friendsofphp/php-cs-fixer 162 | - Any library or PSR published by the PHP-FIG 163 | 164 | Explicitly rejected libraries 165 | ----------------------------- 166 | 167 | None 168 | 169 | Marketing Material 170 | ================== 171 | 172 | Marketing material MAY reference and link to third party libraries, provided 173 | that the library meets all of the “Inclusion” criteria, and does not meet any of 174 | the “Exclusion” criteria. Additionally, the language used to refer to the 175 | library must also follow the criteria below. 176 | 177 | Inclusion criteria 178 | ------------------ 179 | 180 | #. The library must have a stable >= 1.0 release, and have had one for at least 181 | a year. 182 | 183 | #. The library provides a use that is commonly needed by many types of projects, 184 | making it of *significant interest to the PHP ecosystem*. 185 | 186 | #. The library is a recognized de facto standard, or one of a small number of de 187 | facto standards, in its problem space. If there are a small number of de 188 | facto standard libraries, then all should be listed and given equal weight. 189 | 190 | #. The library MAY be a Web Application, provided its mention clearly does not 191 | specifically endorse the Application. If many options exist in a space that 192 | bears mention, the most common should be given equal exposure. 193 | 194 | #. The library is available under an Approved License. 195 | 196 | #. The language used to describe the library does not imply that the PHP Project 197 | is involved in or specifically recommends the library over some other. 198 | 199 | Exclusion criteria 200 | ------------------ 201 | 202 | #. The library is not available under an Approved License. 203 | #. The library has shown no meaningful activity for one year prior to its first 204 | mention. 205 | #. The library is not of broad interest to the PHP ecosystem. 206 | 207 | PHP marketing material maintainers MAY use their judgement to determine if a 208 | library meets the above criteria, but SHOULD be conservative in their 209 | interpretation of whether or not a library satisfies the necessary criteria. 210 | 211 | Explicitly approved libraries 212 | ----------------------------- 213 | 214 | The following libraries have been explicitly approved by RFC vote. 215 | 216 | - Composer 217 | - Xdebug 218 | - phpunit/phpunit 219 | - phpstan/phpstan 220 | - vimeo/psalm 221 | - squizlabs/php_codesniffer 222 | - friendsofphp/php-cs-fixer 223 | - Any library or PSR published by the PHP-FIG 224 | 225 | Explicitly rejected libraries 226 | ----------------------------- 227 | 228 | None 229 | 230 | ********************* 231 | Conflict Resolution 232 | ********************* 233 | 234 | Should there be a reasonable dispute as to whether a given library satisfies the 235 | criteria above, an RFC may be posted to explicitly approve the library for one 236 | or more of the above cases. The RFC MUST have a 2/3 vote threshold to approve 237 | the library. If the library is rejected, it may be revisited after six months, 238 | like any other RFC. 239 | 240 | Additionally, a library that does not satisfy the above criteria MAY be granted 241 | an exception by RFC vote. The RFC MUST acknowledge the reasons the library does 242 | not meet the above criteria and why it is necessary for the PHP project to make 243 | use of or reference it anyway. The RFC MUST have a 2/3 vote threshold to approve 244 | the library. 245 | 246 | ********************* 247 | Approved Exceptions 248 | ********************* 249 | 250 | PHP Tooling 251 | =========== 252 | 253 | - Dokuwiki 254 | --------------------------------------------------------------------------------