rfc:experimental

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

rfc:experimental [2014/10/28 19:03]
krakjoe
rfc:experimental [2017/09/22 13:28]
Line 1: Line 1:
-====== PHP RFC: Experimental ====== 
-  * Version: 0.9 
-  * Date: 2014-10-28 ​ 
-  * Author: krakjoe 
-  * Status: Draft 
-  * First Published at: http://​wiki.php.net/​rfc/​experimental 
  
-===== Introduction ===== 
-This RFC aims to come to an agreement on how new code merged into php-src should be developed and maintained. 
- 
-===== Proposal ===== 
- 
-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 2 years. 
- 
-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. 
- 
-===== Implementation ===== 
-No implementation is required, only an update to the current version of CODING_STANDARDS which contains the current definition of experimental. 
rfc/experimental.txt · Last modified: 2017/09/22 13:28 (external edit)