From 1bbfc0d6ebc9171f8bba4b30e9923e7c49c6bc24 Mon Sep 17 00:00:00 2001 From: Donald Stufft Date: Wed, 17 Dec 2014 21:16:19 -0500 Subject: [PATCH] Switch from preferring c to rc for release candidates --- pep-0440.txt | 66 +++++++++++++++++++++++++++------------------------- 1 file changed, 34 insertions(+), 32 deletions(-) diff --git a/pep-0440.txt b/pep-0440.txt index 6739c4491..ec325ad15 100644 --- a/pep-0440.txt +++ b/pep-0440.txt @@ -64,7 +64,7 @@ Public version identifiers The canonical public version identifiers MUST comply with the following scheme:: - [N!]N(.N)*[{a|b|c}N][.postN][.devN] + [N!]N(.N)*[{a|b|rc}N][.postN][.devN] Public version identifiers MUST NOT include leading or trailing whitespace. @@ -79,7 +79,7 @@ Public version identifiers are separated into up to five segments: * Epoch segment: ``N!`` * Release segment: ``N(.N)*`` -* Pre-release segment: ``{a|b|c}N`` +* Pre-release segment: ``{a|b|rc}N`` * Post-release segment: ``.postN`` * Development release segment: ``.devN`` @@ -241,10 +241,10 @@ support testing by their users prior to a final release. If used as part of a project's development cycle, these pre-releases are indicated by including a pre-release segment in the version identifier:: - X.YaN # Alpha release - X.YbN # Beta release - X.YcN # Candidate release - X.Y # Final release + X.YaN # Alpha release + X.YbN # Beta release + X.YrcN # Release Candidate + X.Y # Final release A version identifier that consists solely of a release segment and a pre-release segment is termed a "pre-release". @@ -257,11 +257,11 @@ and then by the numerical component within that phase. Installation tools MAY accept both ``c`` and ``rc`` releases for a common release segment in order to handle some existing legacy distributions. -Installation tools SHOULD interpret ``rc`` versions as being equivalent to -``c`` versions (that is, ``rc1`` indicates the same version as ``c1``). +Installation tools SHOULD interpret ``c`` versions as being equivalent to +``rc`` versions (that is, ``c1`` indicates the same version as ``rc1``). Build tools, publication tools and index servers SHOULD disallow the creation -of both ``c`` and ``rc`` releases for a common release segment. +of both ``rc`` and ``c`` releases for a common release segment. Post-releases @@ -293,9 +293,9 @@ and ahead of any subsequent release. Post-releases are also permitted for pre-releases:: - X.YaN.postM # Post-release of an alpha release - X.YbN.postM # Post-release of a beta release - X.YcN.postM # Post-release of a release candidate + X.YaN.postM # Post-release of an alpha release + X.YbN.postM # Post-release of a beta release + X.YrcN.postM # Post-release of a release candidate .. note:: @@ -331,10 +331,10 @@ any previous release (including any post-releases). Developmental releases are also permitted for pre-releases and post-releases:: - X.YaN.devM # Developmental release of an alpha release - X.YbN.devM # Developmental release of a beta release - X.YcN.devM # Developmental release of a release candidate - X.Y.postN.devM # Developmental release of a post-release + X.YaN.devM # Developmental release of an alpha release + X.YbN.devM # Developmental release of a beta release + X.YrcN.devM # Developmental release of a release candidate + X.Y.postN.devM # Developmental release of a post-release .. note:: @@ -423,11 +423,12 @@ such as ``1.0a.1`` which would be normalized to ``1.0a1``. Pre-release spelling ~~~~~~~~~~~~~~~~~~~~ -Pre-releases allow the additional spellings of ``alpha``, ``beta``, ``rc``, -``pre``, and ``preview`` for ``a``, ``b``, ``c``, ``c``, and ``c`` respectively. -This allows versions such as ``1.1alpha1``, ``1.1beta2``, or ``1.1rc3`` which -normalize to ``1.1a1``, ``1.1b2``, and ``1.1c3``. In every case the additional -spelling should be considered equivalent to their normal forms. +Pre-releases allow the additional spellings of ``alpha``, ``beta``, ``c``, +``pre``, and ``preview`` for ``a``, ``b``, ``rc``, ``rc``, and ``rc`` +respectively. This allows versions such as ``1.1alpha1``, ``1.1beta2``, or +``1.1c3`` which normalize to ``1.1a1``, ``1.1b2``, and ``1.1rc3``. In every +case the additional spelling should be considered equivalent to their normal +forms. Implicit pre-release number @@ -561,7 +562,7 @@ pre-releases:: 1.0a1 1.0a2 1.0b1 - 1.0c1 + 1.0rc1 1.0 1.1a1 ... @@ -574,8 +575,8 @@ and post-releases for minor corrections:: 1.0.dev2 1.0.dev3 1.0.dev4 - 1.0rc1 - 1.0rc2 + 1.0c1 + 1.0c2 1.0 1.0.post1 1.1.dev1 @@ -619,15 +620,15 @@ consistent length by padding shorter segments with zeros as needed. Within a numeric release (``1.0``, ``2.7.3``), the following suffixes are permitted and MUST be ordered as shown:: - .devN, aN, bN, cN/rcN, , .postN + .devN, aN, bN, rcN, , .postN -Note that `rc` is considered to be semantically equivalent to `c` and must be -sorted as if it were `c`. Tools MAY reject the case of having the same ``N`` -for both a ``rc`` and a ``c`` in the same release segment as ambiguous and +Note that `c` is considered to be semantically equivalent to `rc` and must be +sorted as if it were `rc`. Tools MAY reject the case of having the same ``N`` +for both a ``c`` and a ``rc`` in the same release segment as ambiguous and remain in compliance with the PEP. Within an alpha (``1.0a1``), beta (``1.0b1``), or release candidate -(``1.0c1``, ``1.0rc1``), the following suffixes are permitted and MUST be +(``1.0rc1``, ``1.0c1``), the following suffixes are permitted and MUST be ordered as shown:: .devN, , .postN @@ -655,8 +656,8 @@ The following example covers many of the possible combinations:: 1.0b2 1.0b2.post345.dev456 1.0b2.post345 - 1.0c1.dev456 - 1.0c1 + 1.0rc1.dev456 + 1.0rc1 1.0 1.0+abc.5 1.0+abc.7 @@ -1221,6 +1222,8 @@ Summary of differences from \PEP 386 * Discuss ordering and dependencies across metadata versions +* Switch from preferring ``c`` to ``rc``. + The rationale for major changes is given in the following sections. @@ -1484,7 +1487,6 @@ reason for this is that the Wheel normalization scheme specifies that ``-`` gets normalized to a ``_`` to enable easier parsing of the filename. - References ==========