Everything
php
Accepted Policy
RFC Categories
Separation of Third-Party Extension Documentation
The PHP manual currently contains documentation for both PHP itself and numerous independently maintained third-party extensions.
Move third-party extension documentation out of the official PHP manual?
Yes
26 Votes (93%)
No
1 Votes (4%)
Abstain
1 Votes (4%)
Where should third-party documentation be hosted?
contrib.php.net (subdomain)
8 Votes (28%)
www.php.net/manual/extensions/ (subpath)
15 Votes (52%)
Abstain
6 Votes (21%)
How should existing user notes be handled during migration?
Remove notes
21 Votes (75%)
Migrate notes to the new location
4 Votes (14%)
Abstain
3 Votes (11%)
Release Manager Selection
The current policy about the Release Manager Selection process is using unclear and confusing terminology and allows for decisions to be made that no longer mat...
Accept php/policies PR #28 (Clarify policy for Release Manager Selection) at commit d887ee1e1ece6a46d1d621d2d551474cb15ea161?
Yes
17 Votes (63%)
No
6 Votes (22%)
Abstain
4 Votes (15%)
PHP Policy RFC: Exempt input type and value validation from BC Break policy
PHP's release cycle does not only affect the release of the core language,
but also all extensions that are bundled.
Bundled extensions are all the extensions t...
Accept php/policies PR #27?
Yes
26 Votes (76%)
No
5 Votes (15%)
Abstain
3 Votes (9%)
Clarify discussion and voting period rules
The current written policy governing the RFC process no longer matches the current process practiced and expected by the community.
Accept php/policies PR #23 (Clarify discussion and voting period rules) at commit c087d812e694a9fb1371b871c4372305f0cb5cbe?
Yes
24 Votes (77%)
No
6 Votes (19%)
Abstain
1 Votes (3%)
Recommend PIE and deprecate PECL
The RFC proposes to deprecate PECL, and to adopt PHP Installer for Extensions (PIE) going forward.
Deprecate PECL and adopt PIE instead?
Yes
36 Votes (88%)
No
0 Votes (0%)
Abstain
5 Votes (12%)
Abstain voting option for RFCs
It is commonly the case that RFC voters do not feel strongly about an individual RFC, but the current voting guidelines make it impossible to express this.
Accept php/policies PR #20 (Add Abstain voting option and update phrasing for the voting) at commit de94b7a132c4a74e54e7848914203f1849231697?
Yes
27 Votes (68%)
No
7 Votes (18%)
Abstain
6 Votes (15%)
PHP License Update
PHP has a long history of confusion, concerns, and disagreements regarding its custom open source license, and the Zend Engine License, which covers the sources...
Publish the PHP License, version 4, and Zend Engine License, version 3, by adopting the Modified BSD License as the new version of both, and deprecate the PHP License and Zend Engine License, as proposed in the Proposal section
Yes
51 Votes (96%)
No
0 Votes (0%)
Abstain
2 Votes (4%)
Policy release process update
This is a policy RFC that tries to match the current policy with the process that we currently have and also clarify few details.
Update the release process as proposed?
Yes
15 Votes (79%)
No
0 Votes (0%)
Abstain
4 Votes (21%)
Throwable Hierarchy Policy for Extensions
PHP has a number of de facto rules and policies around the use of exceptions in extensions, for example not to use SPL exceptions in new code, but no official d...
Accept php/policies PR #17 (Add Throwable policy) at commit cf4cfb3ea95e3a59a56a395e1fae00ff9722e0cd?
Yes
25 Votes (96%)
No
1 Votes (4%)
Casing of acronyms in class and method names
The results of the Class Naming RFC decided that class names should be written in PascalCase (Upper Camel Case), with the exception of acronyms, which should be...
Adopt the updated class naming policy and adjust the new names introduced in PHP 8.4?
yes
23 Votes (96%)
no
1 Votes (4%)
Release cycle update
The current release cycle has been introduced in 2010 by release process RFC. This has been
working mostly well, but there have been some minor issues. The leng...
Allow features that do not require an RFC in the beta period
Yes
34 Votes (100%)
No
0 Votes (0%)
Disallow New Features in Release Candidates and Bug Fix releases
Yes
32 Votes (100%)
No
0 Votes (0%)
Reduce number of RCs to Four
Yes
30 Votes (91%)
No
3 Votes (9%)
Extend Security Support by One Year
Yes
31 Votes (100%)
No
0 Votes (0%)
Allowing recent regression fixes during security support
Yes
30 Votes (100%)
No
0 Votes (0%)
Extend Releases Cycle to End of Year
Yes
33 Votes (100%)
No
0 Votes (0%)
Promote the PHP Foundation
The PHP Foundation was created to support, advance, and develop the PHP Language and currently funds a team of ten developers to foster that goal. There is curr...
Should we place text and a link to the PHP Foundation on PHP.net to promote them as a financial sponsor of the project?
yes
27 Votes (100%)
no
0 Votes (0%)
Migrating to GitHub Issues
This RFC proposes to use GitHub Issues on the PHP repository in place of our own bugs.php.net bug tracker.
Migrate from bugs.php.net to GitHub issues as proposed?
Yes
41 Votes (91%)
No
4 Votes (9%)
Namespaces in bundled PHP extensions
Classes and functions provided by bundled PHP extensions are currently all located in the global namespace (with one exception). There is a strong sentiment tha...
Allow use of namespaces in line with these guidelines?
Yes
37 Votes (97%)
No
1 Votes (3%)
Class Naming
The PHP coding standard does not cover how class names should be written. This leads to friction within the userland community that is now largely following the...
Should we update the coding standard?
Yes
17 Votes (65%)
No
9 Votes (35%)
What class naming style should we use?
PascalCase except Acronyms
15 Votes (58%)
Always PascalCase
11 Votes (42%)
Deprecate MD5 checksums from Release process
MD5 should not be considered cryptographically secure for verifying download integrity. We're already providing both SHA256 hashes and GPG signatures for this ...
Should MD5 checksums be left in or removed?
Remove
29 Votes (100%)
Keep
0 Votes (0%)
Remove immediately or deprecate prior to removal?
Remove Now
29 Votes (97%)
Deprecate
1 Votes (3%)
Abolish Narrow Margins
When the RFC process was enshrined in internal law, we were very aware that setting the bar too high for new features may reduce the number of contributors we h...
Adopt the changes in this proposal?
Yes
30 Votes (94%)
No
2 Votes (6%)
Officially adopt the proposed security issue classification scheme ?
Yes
18 Votes (100%)
No
0 Votes (0%)
Cleaning up unmaintained extensions
We have a number of extensions that have no assigned maintainer. The proposal is either to find a maintainer for them
or move them out of core. The RFC proposes...
Institute the policy of cleaning up unmaintained extensions as described in this RFC
Yes
19 Votes (83%)
No
4 Votes (17%)
PHP 5 Support Timeline
This RFC proposes to extend the End of Active Support & End of Security Support dates for PHP 5.6, the final version in the PHP 5 family.
Extend the support timeline of PHP 5?
Yes
42 Votes (95%)
No
2 Votes (5%)
Extend the support timeline to:
1 year Active Support 1 year Security Support
21 Votes (48%)
1 year Active Support 2 years Security Support
23 Votes (52%)
Reserved Type: resource
Yes
40 Votes (69%)
No
18 Votes (31%)
Reserved Type: scalar
Yes
34 Votes (64%)
No
19 Votes (36%)
Reserved Type: object
Yes
45 Votes (82%)
No
10 Votes (18%)
Reserved Type: mixed
Yes
41 Votes (73%)
No
15 Votes (27%)
Reserved Type: numeric
Yes
44 Votes (79%)
No
12 Votes (21%)
Consolidate Coding Standards Policy Document
This RFC is the follow-up on the Policy Repository RFC. That RFC created the Policies Repository, but made no changes to existing documents. An item under Futur...
Rewrite Coding Standards and Naming Document with Suggested Patch?
yes
13 Votes (100%)
no
0 Votes (0%)
PHP 7.0 timeline
With key decisions about both the version number and the engine for PHP 7 behind us, it's time to define an agreed-upon timeline so that all contributors can al...
php7timeline
Yes
34 Votes (94%)
No
2 Votes (6%)
Name of Next Release of PHP
There has been some debate over what the name of the next major release of PHP, to succeed the PHP 5.x series, should be called. This RFC is an attempt to settl...
Shall the name of PHP NEXT be PHP 6, or PHP 7?
PHP 6
24 Votes (29%)
PHP 7
58 Votes (71%)
Keeping PHPT Tests Green
We have a setup on Travis CI which automatically
runs PHPT tests for our active branches. This is very convenient for
evaluating pull request and status of the ...
Accept the description in this RFC as an official policy of the PHP project with regard to the tests
Yes
16 Votes (100%)
No
0 Votes (0%)
Choose one or more of the four options above of handling bad commits
Revert ASAP
14 Votes (39%)
Revert after 1 week
4 Votes (11%)
XFAIL
8 Votes (22%)
Update test
10 Votes (28%)
Define PHP 5.3 end of life
The purpose of this RFC is to define when the PHP 5.3 series will no longer be supported.
Which EOL period should we choose?
Two years, one normal fixes and one security fixes only, announce with the next 5.3 release
0 Votes (0%)
Two years, one normal fixes and one security fixes only, announce with 5.5 final release
12 Votes (26%)
Two years with security fixes only, announce with the next 5.3 release
0 Votes (0%)
Two years with security fixes only, announce with 5.5 final release
3 Votes (6%)
One year with normal and security fixes, announce with the next 5.3 release
0 Votes (0%)
One year with normal and security fixes, announce with 5.5 final release
1 Votes (2%)
One year with security fixes only, announce with the next 5.3 release
0 Votes (0%)
One year with security fixes only, announce with 5.5 final release
31 Votes (66%)
Choosing a distributed version control system for PHP
PHP uses Subversion (SVN) as its version control system of choice at the
moment. This has a few drawbacks. A decentralized version control system
can solve some...
Voting on PHP features
This document describes the procedure to propose an idea for adoption by the PHP community and decide if the community accepts or rejects the idea.
Release Process
PHP releases have always been done spontaneously, in a somehow chaotic way. Individual(s) decided when a release will happen and what could or could fit in. Rel...