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

PEP 426: clarify metadata version transitions

This commit is contained in:
Nick Coghlan 2013-02-18 22:02:45 +10:00
parent 0c893b0ffe
commit 57dc04d92a
1 changed files with 22 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
pep-0426.txt
View File

@ -89,9 +89,15 @@ Metadata-Version
Version of the file format; "2.0" is the only legal value.
Automated tools should warn if ``Metadata-Version`` is greater than the
highest version they support, and must fail if ``Metadata-Version`` has
a greater major version than the highest version they support.
Automated tools consuming metadata should warn if ``Metadata-Version`` is
greater than the highest version they support, and must fail if
``Metadata-Version`` has a greater major version than the highest
version they support.
For broader compatibility, automated tools may choose to produce
distribution metadata using the lowest metadata version that includes
all of the needed fields.
Example::
@ -1283,9 +1289,19 @@ accordingly, as interpreting PEP 426 metadata in accordance with earlier
metadata specifications is unlikely to give the expected behaviour.
Whenever the major version number of the specification is incremented, it
is expected that deployment will take some time, as metadata consuming tools
much be updated before other tools can safely start producing the new
format.
is expected that deployment will take some time, as either metadata
consuming tools must be updated before other tools can safely start
producing the new format, or else the sdist and wheel formats, along with
the installation database definition, will need to be updated to support
provision of multiple versions of the metadata in parallel.
Existing tools won't abide by this guideline until they're updated to
support the new metadata standard, so the new semantics will first take
effect for a hypothetical 2.x -> 3.0 transition. For the 1.x -> 2.0
transition, it is recommended that tools continue to produce the
existing supplementary files (such as ``entry_points.txt``) in addition
to any equivalents specified using the new features of the standard
metadata format (including the formal extension mechanism).
Standard encoding and other format clarifications