This is an old revision of the document!
PHP RFC: Experimental
- Version: 0.9
- Date: 2014-10-28
- Author: krakjoe
- Status: Draft
- First Published at: http://wiki.php.net/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 as follows:
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. 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, can be considered experimental for a maximum of 1 year.
This allows the definition to apply to SAPI and extension code, and further clarifies what we can consider experimental.
Staging Process for Experimental Code
Experimental code can be developed in an experimental branch of php-src or an external repository.
Experimental does not mean unstable; every effort should be made to stabilize code before merging is suggested.
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 7 days, a merge to production or development branches is permitted after discussion with release manager(s) has taken place.
After the defined period for experimental code has passed, the experimental notice must be removed and the code subject to the normal internals process.
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.
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)
If we decide against adopting the staging process for experimental code, experimental code will be subject to the normal internals process.
No implementation is required, only an update to the current version of CODING_STANDARDS which contains the current definition of experimental.