iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Switch from preferring c to rc for release candidates

This commit is contained in:
Donald Stufft 2014-12-17 21:16:19 -05:00
parent c508f9012b
commit 1bbfc0d6eb
1 changed files with 34 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

66
pep-0440.txt
View File

@ -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, <no suffix>, .postN
.devN, aN, bN, rcN, <no suffix>, .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, <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.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
==========