Discussions-To: Distutils SIG <email@example.com>
Post-History: 30 Mar 2013, 27 May 2013, 20 Jun 2013,
Distributions are identified by a public version identifier which
supports all defined version comparison operations
-Distributions may also define a source label, which is not used by
-automated tools. Source labels are useful when a project internal
-versioning scheme requires translation to create a compliant public
The version scheme is used both to describe the distribution version
provided by a particular distribution archive, as well as to place
constraints on the version of dependencies needed in order to build or
``python.integrator`` extension metadata (as defined in :pep:`459`).
-Source labels are text strings with minimal defined semantics. They are
-intended to allow the original source code to be unambiguously identified,
-even if an integrator has applied additional local modifications to a
-To ensure source labels can be readily incorporated as part of file names
-and URLs, and to avoid formatting inconsistencies in hexadecimal hash
-representations they MUST be limited to the following set of permitted
-* Lowercase ASCII letters (``[a-z]``)
-* ASCII digits (``[0-9]``)
-Source labels MUST start and end with an ASCII letter or digit.
-A source label for a project MUST NOT match any defined version for that
-project. This restriction ensures that there is no ambiguity between version
-identifiers and source labels.
Some projects may choose to use a version scheme which requires
translation in order to comply with the public version scheme defined in
-this PEP. In such cases, the source label can be used to
-record the project specific version as an arbitrary label, while the
-translated public version is published in the version field.
+this PEP. In such cases, the project project specific version can be stored
+in the metadata while the translated public version is published in the version
This allows automated distribution tools to provide consistently correct
ordering of published releases, while still allowing developers to use
permitted in the public version field.
As with semantic versioning, the public ``.devN`` suffix may be used to
-uniquely identify such releases for publication, while the source label is
-used to record the original DVCS based version label.
+uniquely identify such releases for publication, while the original DVCS based
+label can be stored in the project metadata.
Identifying hash information may also be included in local version labels.
As with other translated version identifiers, the corresponding Olson
-database version could be recorded in the
source label field.
+database version could be recorded in the .
* Moved the description of version specifiers into the versioning PEP
-* Added the "source label" concept to better handle projects that wish to
- use a non-compliant versioning scheme internally, especially those based
* Added the "direct reference" concept as a standard notation for direct
references to resources (rather than each tool needing to invent its own)
The rationale for major changes is given in the following sections.
-The new source label support is intended to make it clearer that the
-constraints on public version identifiers are there primarily to aid in
-the creation of reliable automated dependency analysis tools. Projects
-are free to use whatever versioning scheme they like internally, so long
-as they are able to translate it to something the dependency analysis tools
-Source labels also make it straightforward to record specific details of a
-version, like a hash or tag name that allows the release to be reconstructed
-from the project version control system.
Changing the version scheme