Commits

Donald Stufft  committed d205a04

Move the source label to the Metadata 2.0 PEP

  • Participants
  • Parent commits b7265f9

Comments (0)

Files changed (2)

File core-metadata.rst

 operation depending on one of these fields is requested.
 
 
-Source label
-------------
-
-A constrained identifying text string, as defined in PEP 440. Source labels
-cannot be used in version specifiers - they are included for information
-purposes only.
-
-Source labels MUST meet the character restrictions defined in PEP 440.
-
-Source labels MUST be unique within each project and MUST NOT match any
-defined version for the project.
+Source labels
+-------------
+
+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
+particular distribution.
+
+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
+characters:
+
+* Lowercase ASCII letters (``[a-z]``)
+* ASCII digits (``[0-9]``)
+* underscores (``_``)
+* hyphens (``-``)
+* periods (``.``)
+* plus signs (``+``)
+
+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.
 
 Examples::
 
 Source labels
 -------------
 
-See PEP 440 for the rationale behind the addition of this field.
+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
+will understand.
+
+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.
 
 
 Support for different kinds of dependencies

File versioning.rst

 Discussions-To: Distutils SIG <distutils-sig@python.org>
 Status: Draft
 Type: Standards Track
-Content-Type: text/x-rst
+Content-Type: text/x-rsts
 Created: 18 Mar 2013
 Post-History: 30 Mar 2013, 27 May 2013, 20 Jun 2013,
               21 Dec 2013, 28 Jan 2014
 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
-version identifier.
-
 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
--------------
-
-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
-particular distribution.
-
-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
-characters:
-
-* Lowercase ASCII letters (``[a-z]``)
-* ASCII digits (``[0-9]``)
-* underscores (``_``)
-* hyphens (``-``)
-* periods (``.``)
-* plus signs (``+``)
-
-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.
-
-
 Final releases
 --------------
 
 
 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
+field.
 
 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.
 
 update within the year.
 
 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 project metadata.
 
 
 Version specifiers
 
 * 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
-  on DVCS hashes
-
 * 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.
 
 
-Adding source labels
---------------------
-
-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
-will understand.
-
-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
 ---------------------------