This is an old revision of the document!

PHP RFC: Experimental


This RFC aims to come to an agreement on how new code merged into php-src should be developed and maintained.


We propose to amend the current definition of experimental:

  Experimental Code
  To reduce the problems associated with the first public implementations, 
  it is required that the experimental code's source directory include a 
  file named 'EXPERIMENTAL', which should include the following information:
   * Any authoring information (known bugs, future directions of the module).
   * Ongoing status notes which may not be appropriate for Git comments.
  If possible, new features should go to PECL or experimental branches until 
  there are specific reasons for directly adding it to the core distribution.
  Experimental code being distributed with PHP must follow coding standards.
  Any code that is merged with an existing user base depending on it 
  cannot be marked as experimental.
  New code, with no user base, is considered experimental for X releases/moons/elephants.

This allows the definition to apply to SAPI and extension code, and further clarifies what we can consider experimental.

We propose we make a decision as to how such experimental code should be developed:

  • experimental code is immediately subject to the normal internals process.
  • experimental code is developed using a staging process.

Staging Process for Experimental Code

Experimental code can be developed in an experimental branch of php-src or an external repository.

Before any merges into production or development branches of php-src, maintainers of experimental code must invite discussion on internals, for anything other than bug and security fixes.

Discussion of such merges must lead to an RFC in the case that an agreement about implementation details cannot be reached on internals.

Only if there are no objections to a merge from internals after a period of 1 week/moon/elephant, a merge to production or development branches is permitted after discussion with release manager(s) has taken place.

This allows experimental code to be developed at a different pace to production or development branches of PHP, but still requires that the maintainers are in communication with internals.

After the defined period for experimental code has passed, the experimental notice must be removed and the code subject to the normal internals process.

Proposed Voting Choices

There will be two votes:

  • Adopt the proposed definition of experimental (yes/no)
  • Adopt the proposed staging process for experimental code (yes/no)


No implementation is required, only an update to the current version of CODING_STANDARDS which contains the current definition of experimental.

rfc/experimental.1414521279.txt.gz · Last modified: 2017/09/22 13:28 (external edit)