Switch from preferring c to rc for release candidates

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``
 
@@ -243,7 +243,7 @@ indicated by including a pre-release segment in the version identifier::
 
     X.YaN   # Alpha release
     X.YbN   # Beta release
-    X.YcN  # Candidate release
+    X.YrcN  # Release Candidate
     X.Y     # Final release
 
 A version identifier that consists solely of a release segment and a
@@ -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
+Installation tools SHOULD interpret ``c`` versions as being equivalent to
-``c`` versions (that is, ``rc1`` indicates the same version as ``c1``).
+``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
@@ -295,7 +295,7 @@ 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.YrcN.postM  # Post-release of a release candidate
 
 .. note::
 
@@ -333,7 +333,7 @@ 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.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-releases allow the additional spellings of ``alpha``, ``beta``, ``c``,
-``pre``, and ``preview`` for ``a``, ``b``, ``c``, ``c``, and ``c`` respectively.
+``pre``, and ``preview`` for ``a``, ``b``, ``rc``, ``rc``, and ``rc``
-This allows versions such as ``1.1alpha1``, ``1.1beta2``, or ``1.1rc3`` which
+respectively. This allows versions such as ``1.1alpha1``, ``1.1beta2``, or
-normalize to ``1.1a1``, ``1.1b2``, and ``1.1c3``. In every case the additional
+``1.1c3`` which normalize to ``1.1a1``, ``1.1b2``, and ``1.1rc3``. In every
-spelling should be considered equivalent to their normal forms.
+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.0c1
-    1.0rc2
+    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, <no suffix>, .postN
+   .devN, aN, bN, rcN, <no suffix>, .postN
 
-Note that `rc` is considered to be semantically equivalent to `c` and must be
+Note that `c` is considered to be semantically equivalent to `rc` and must be
-sorted as if it were `c`. Tools MAY reject the case of having the same ``N``
+sorted as if it were `rc`. 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
+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, <no suffix>, .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.0rc1.dev456
-    1.0c1
+    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
 ==========