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, is considered experimental for [Open Issue 1]
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 [Open Issue 2], 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.
- How long can experimental code be considered experimental ? (Suggest: 1 release cycle/1 year)
- How long should developers wait for a response from internals before approaching an RM to discuss merging new code ? (Suggest: 7 days)
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.