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 all ``rc`` versions as coming after all
-``c`` versions (that is, ``rc1`` indicates a later version than ``c2``).
-Installation tools MAY warn the user when such ambiguous versions are
-detected, or even reject them entirely.
+Installation tools SHOULD interpret ``rc`` versions as being equivalent to
+``c`` versions (that is, ``rc1`` indicates the same version as ``c1``).
Build tools, publication tools and index servers SHOULD disallow the creation
of both ``c`` and ``rc`` releases for a common release segment.
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, cNrcN, <no suffix>, .postN
-Note that `rc` will always sort after `c` (regardless of the numeric
-component) although they are semantically equivalent. Tools MAY
-reject this case as ambiguous and remain in compliance with the PEP.
+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
+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