From e67686bb72774196ba9b5fc50cc07c8b4548ac14 Mon Sep 17 00:00:00 2001 From: Eli Bendersky Date: Fri, 10 Feb 2012 07:14:46 +0200 Subject: [PATCH] fixes and cleanups --- pep-0411.txt | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/pep-0411.txt b/pep-0411.txt index b6f0bf38b..ee641ba5e 100644 --- a/pep-0411.txt +++ b/pep-0411.txt @@ -35,8 +35,8 @@ Proposal - a documented provisional state Whenever the Python core development team decides that a new package should be included into the standard library, but isn't entirely sure about whether the -package's API is optimal, the package can be included and placed in a special -"provisional" state. +package's API is optimal, the package can be included and marked as +"provisional". In the next minor release, the package may either be "graduated" into a normal "stable" state in the standard library, or be rejected and removed entirely @@ -46,6 +46,7 @@ changed according to accumulated feedback. The core development team explicitly makes no guarantees about API stability and backward compatibility of provisional packages. + Marking a package provisional ----------------------------- @@ -60,6 +61,10 @@ a note at the top of its documentation page: serious API flaws are uncovered that were missed prior to inclusion of the package. +Moving a package from the provisional to the stable state simply implies +removing this note from its documentation page. + + Which packages should go through the provisional state ------------------------------------------------------ @@ -82,7 +87,7 @@ stable standard library. Some reasons for not graduating are: * The package may prove to be unstable or fragile, without sufficient developer support to maintain it. -* A much better alternative package may be found during the preview release +* A much better alternative package may be found during the preview release. Essentially, the decision will be made by the core developers on a per-case basis. The point to emphasize here is that a packages's inclusion in the @@ -122,7 +127,7 @@ are more likely to be just be an import away. For environments where developers are required to conduct due diligence on their upstream dependencies (severely harming the cost-effectiveness of, or even ruling out entirely, much of the material on PyPI), the key benefit lies -in ensuring that all modules in the provisional state are clearly under +in ensuring that all packages in the provisional state are clearly under python-dev's aegis from at least the following perspectives: * Licensing: Redistributed by the PSF under a Contributor Licensing Agreement.