Source

misc / pep_drafts / pep-0440.txt

Full commit
   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
PEP: 440
Title: Version Identification and Dependency Specification
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan <ncoghlan@gmail.com>
BDFL-Delegate: Nick Coghlan <ncoghlan@gmail.com>
Discussions-To: Distutils SIG <distutils-sig@python.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 18 Mar 2013
Post-History: 30 Mar 2013, 27-May-2013
Replaces: 386


Abstract
========

This PEP describes a scheme for identifying versions of Python software
distributions, and declaring dependencies on particular versions.

This document addresses several limitations of the previous attempt at a
standardised approach to versioning, as described in PEP 345 and PEP 386.

.. note::

   This PEP was broken out of the metadata 2.0 specification in PEP 426.

   Unlike PEP 426, the notes that remain in this document are intended as
   part of the final specification.


Definitions
===========

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

The following terms are to be interpreted as described in PEP 426:

* "Distributions"
* "Versions"
* "Build tools"
* "Index servers"
* "Publication tools"
* "Installation tools"
* "Automated tools"
* "Projects"


Version scheme
==============

Distribution versions are identified by both a public version identifier,
which supports all defined version comparison operations, and a build
label, which supports only strict equality comparisons.

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
run the software.


Public version identifiers
--------------------------

Public version identifiers MUST comply with the following scheme::

    N[.N]+[{a|b|c|rc}N][.postN][.devN]

Public version identifiers MUST NOT include leading or trailing whitespace.

Public version identifiers MUST be unique within a given distribution.

Installation tools SHOULD ignore any public versions which do not comply with
this scheme. Installation tools MAY warn the user when non-compliant
or ambiguous versions are detected.

Public version identifiers are separated into up to four segments:

* Release segment: ``N[.N]+``
* Pre-release segment: ``{a|b|c|rc}N``
* Post-release segment: ``.postN``
* Development release segment: ``.devN``

Any given version will be a "release", "pre-release", "post-release" or
"developmental release" as defined in the following sections.

.. note::

   Some hard to read version identifiers are permitted by this scheme in
   order to better accommodate the wide range of versioning practices
   across existing public and private Python projects.

   Accordingly, some of the versioning practices which are technically
   permitted by the PEP are strongly discouraged for new projects. Where
   this is the case, the relevant details are noted in the following
   sections.


Build labels
------------

Build labels are text strings with minimal defined semantics.

To ensure build labels can be readily incorporated as part of file names
and URLs, they MUST be comprised of only ASCII alphanumerics, plus signs,
periods and hyphens.

In addition, build labels MUST be unique within a given distribution.

As with distribution names, all comparisons of build labels MUST be case
insensitive.


Releases
--------

A version identifier that consists solely of a release segment is termed
a "release".

The release segment consists of one or more non-negative integer values,
separated by dots::

    N[.N]+

Releases within a project will typically be numbered in a consistently
increasing fashion.

Comparison and ordering of release segments considers the numeric value
of each component of the release segment in turn. When comparing release
segments with different numbers of components, the shorter segment is
padded out with additional zeroes as necessary.

Date based release numbers are declared to be incompatible with this scheme,
as their use is not consistent with the expected API versioning semantics
described below. Accordingly, automated tools SHOULD report an error
when encountering a leading release component greater than or equal
to ``1980``.

While any number of additional components after the first are permitted
under this scheme, the most common variants are to use two components
("major.minor") or three components ("major.minor.micro").

For example::

    0.9
    0.9.1
    0.9.2
    ...
    0.9.10
    0.9.11
    1.0
    1.0.1
    1.1
    2.0
    2.0.1

A release series is any set of release numbers that start with a common
prefix. For example, ``3.3.1``, ``3.3.5`` and ``3.3.9.45`` are all
part of the ``3.3`` release series.

.. note::

   ``X.Y`` and ``X.Y.0`` are not considered distinct release numbers, as
   the release segment comparison rules implicit expand the two component
   form to ``X.Y.0`` when comparing it to any release segment that includes
   three components.


Pre-releases
------------

Some projects use an "alpha, beta, release candidate" pre-release cycle to
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 (alternative notation: X.YrcN)
    X.Y    # Final release

A version identifier that consists solely of a release segment and a
pre-release segment is termed a "pre-release".

The pre-release segment consists of an alphabetical identifier for the
pre-release phase, along with a non-negative integer value. Pre-releases for
a given release are ordered first by phase (alpha, beta, release candidate)
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 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.

Build tools, publication tools and index servers SHOULD disallow the creation
of both ``c`` and ``rc`` releases for a common release segment.


Post-releases
-------------

Some projects use post-releases to address minor errors in a release that
do not affect the distributed software (for example, correcting an error
in the release notes).

If used as part of a project's development cycle, these post-releases are
indicated by including a post-release segment in the version identifier::

    X.Y.postN    # Post-release

A version identifier that includes a post-release segment without a
developmental release segment is termed a "post-release".

The post-release segment consists of the string ``.post``, followed by a
non-negative integer value. Post-releases are ordered by their
numerical component, immediately following the corresponding release,
and ahead of any subsequent release.

.. note::

   The use of post-releases to publish maintenance releases containing
   actual bug fixes is strongly discouraged. In general, it is better
   to use a longer release number and increment the final component
   for each maintenance 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

.. note::

   Creating post-releases of pre-releases is strongly discouraged, as
   it makes the version identifier difficult to parse for human readers.
   In general, it is substantially clearer to simply create a new
   pre-release by incrementing the numeric component.


Developmental releases
----------------------

Some projects make regular developmental releases, and system packagers
(especially for Linux distributions) may wish to create early releases
directly from source control which do not conflict with later project
releases.

If used as part of a project's development cycle, these developmental
releases are indicated by including a developmental release segment in the
version identifier::

    X.Y.devN    # Developmental release

A version identifier that includes a developmental release segment is
termed a "developmental release".

The developmental release segment consists of the string ``.dev``,
followed by a non-negative integer value. Developmental releases are ordered
by their numerical component, immediately before the corresponding release
(and before any pre-releases with the same release segment), and following
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

.. note::

   Creating developmental releases of pre-releases is strongly
   discouraged, as it makes the version identifier difficult to parse for
   human readers. In general, it is substantially clearer to simply create
   additional pre-releases by incrementing the numeric component.

   Developmental releases of post-releases are also strongly discouraged,
   but they may be appropriate for projects which use the post-release
   notation for full maintenance releases which may include code changes.


Examples of compliant version schemes
-------------------------------------

The standard version scheme is designed to encompass a wide range of
identification practices across public and private Python projects. In
practice, a single project attempting to use the full flexibility offered
by the scheme would create a situation where human users had difficulty
figuring out the relative order of versions, even though the rules above
ensure all compliant tools will order them consistently.

The following examples illustrate a small selection of the different
approaches projects may choose to identify their releases, while still
ensuring that the "latest release" and the "latest stable release" can
be easily determined, both by human users and automated tools.

Simple "major.minor" versioning::

    0.1
    0.2
    0.3
    1.0
    1.1
    ...

Simple "major.minor.micro" versioning::

    1.1.0
    1.1.1
    1.1.2
    1.2.0
    ...

"major.minor" versioning with alpha, beta and candidate
pre-releases::

    0.9
    1.0a1
    1.0a2
    1.0b1
    1.0c1
    1.0
    1.1a1
    ...

"major.minor" versioning with developmental releases, release candidates
and post-releases for minor corrections::

    0.9
    1.0.dev1
    1.0.dev2
    1.0.dev3
    1.0.dev4
    1.0rc1
    1.0rc2
    1.0
    1.0.post1
    1.1.dev1
    ...


Summary of permitted suffixes and relative ordering
---------------------------------------------------

.. note::

   This section is intended primarily for authors of tools that
   automatically process distribution metadata, rather than developers
   of Python distributions deciding on a versioning scheme.

The release segment of version identifiers MUST be sorted in
the same order as Python's tuple sorting when the release segment is
parsed as follows::

    tuple(map(int, release_segment.split(".")))

All release segments involved in the comparison MUST be converted to a
consistent length by padding shorter segments with zeroes 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

Note that `rc` will always sort after `c` (regardless of the numeric
component) although they are semantically equivalent. Tools are free to
reject this case 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
ordered as shown::

   .devN, <no suffix>, .postN

Within a post-release (``1.0.post1``), the following suffixes are permitted
and MUST be ordered as shown::

    .devN, <no suffix>

Note that ``devN`` and ``postN`` MUST always be preceded by a dot, even
when used immediately following a numeric version (e.g. ``1.0.dev456``,
``1.0.post1``).

Within a pre-release, post-release or development release segment with a
shared prefix, ordering MUST be by the value of the numeric component.

The following example covers many of the possible combinations::

    1.0.dev456
    1.0a1
    1.0a2.dev456
    1.0a12.dev456
    1.0a12
    1.0b1.dev456
    1.0b2
    1.0b2.post345.dev456
    1.0b2.post345
    1.0c1.dev456
    1.0c1
    1.0
    1.0.post456.dev34
    1.0.post456
    1.1.dev1


Version ordering across different metadata versions
---------------------------------------------------

Metadata v1.0 (PEP 241) and metadata v1.1 (PEP 314) do not
specify a standard version identification or ordering scheme. This PEP does
not mandate any particular approach to handling such versions, but
acknowledges that the de facto standard for ordering them is
the scheme used by the ``pkg_resources`` component of ``setuptools``.

Software that automatically processes distribution metadata SHOULD attempt
to normalize non-compliant version identifiers to the standard scheme, and
ignore them if normalization fails. As any normalization scheme will be
implementation specific, this means that projects using non-compliant
version identifiers may not be handled consistently across different
tools, even when correctly publishing the earlier metadata versions.

For distributions currently using non-compliant version identifiers, these
filtering guidelines mean that it should be enough for the project to
simply switch to the use of compliant version identifiers to ensure
consistent handling by automated tools.

Distribution users may wish to explicitly remove non-compliant versions from
any private package indexes they control.

For metadata v1.2 (PEP 345), the version ordering described in this PEP
SHOULD be used in preference to the one defined in PEP 386.


Compatibility with other version schemes
----------------------------------------

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 build 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 allows automated distribution tools to provide consistently correct
ordering of published releases, while still allowing developers to use
the internal versioning scheme they prefer for their projects.


Semantic versioning
~~~~~~~~~~~~~~~~~~~

`Semantic versioning`_ is a popular version identification scheme that is
more prescriptive than this PEP regarding the significance of different
elements of a release number. Even if a project chooses not to abide by
the details of semantic versioning, the scheme is worth understanding as
it covers many of the issues that can arise when depending on other
distributions, and when publishing a distribution that others rely on.

The "Major.Minor.Patch" (described in this PEP as "major.minor.micro")
aspects of semantic versioning (clauses 1-9 in the 2.0.0-rc-1 specification)
are fully compatible with the version scheme defined in this PEP, and abiding
by these aspects is encouraged.

Semantic versions containing a hyphen (pre-releases - clause 10) or a
plus sign (builds - clause 11) are *not* compatible with this PEP
and are not permitted in the public version field.

One possible mechanism to translate such semantic versioning based build
labels to compatible public versions is to use the ``.devN`` suffix to
specify the appropriate version order.

.. _Semantic versioning: http://semver.org/


DVCS based version labels
~~~~~~~~~~~~~~~~~~~~~~~~~

Many build tools integrate with distributed version control systems like
Git and Mercurial in order to add an identifying hash to the version
identifier. As hashes cannot be ordered reliably such versions are not
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 build label is
used to record the original DVCS based version label.


Date based versions
~~~~~~~~~~~~~~~~~~~

As with other incompatible version schemes, date based versions can be
stored in the build label field. Translating them to a compliant
public version is straightforward: use a leading ``"0."`` prefix in the
public version label, with the date based version number as the remaining
components in the release segment.

This has the dual benefit of allowing subsequent migration to version
numbering based on API compatibility, as well as triggering more appropriate
version comparison semantics.


Version specifiers
==================

A version specifier consists of a series of version clauses, separated by
commas. For example::

   0.9, ~= 0.9, >= 1.0, != 1.3.4.*, < 2.0

The comparison operator (or lack thereof) determines the kind of version
clause:
    
* No operator: equivalent to ``~=``
* ``~=``: `Compatible release`_ clause
* ``==``: `Version matching`_ clause
* ``!=``: `Version exclusion`_ clause
* ``is``: `Build reference`_ clause
* ``<=``, ``>=``: `Inclusive ordered comparison`_ clause
* ``<``, ``>``: `Exclusive ordered comparison`_ clause

The comma (",") is equivalent to a logical **and** operator: a candidate
version must match all given version clauses in order to match the
specifier as a whole.

Whitespace between a conditional operator and the following version
identifier is optional, as is the whitespace around the commas.

When multiple candidate versions match a version specifier, the preferred
version SHOULD be the latest version as determined by the consistent
ordering defined by the standard `Version scheme`_. Whether or not
pre-releases are considered as candidate versions SHOULD be handled as
described in `Handling of pre-releases`_.


Compatible release
------------------

A compatible release clause consists of either a version identifier without
any comparison operator or else the compatible release operator ``~=``
and a version identifier. It matches any candidate version that is expected
to be compatible with the specified version.

The specified version identifier must be in the standard format described in
`Version scheme`_.

For a given release identifier ``V.N``, the compatible release clause is
approximately equivalent to the pair of comparison clauses::

    >= V.N, == V.*

For example, the following groups of version clauses are equivalent::

    2.2
    ~= 2.2
    >= 2.2, == 2.*

    1.4.5
    ~= 1.4.5
    >= 1.4.5, == 1.4.*

If a pre-release, post-release or developmental release is named in a
compatible release clause as ``V.N.suffix``, then the suffix is ignored
when determining the required prefix match::

    2.2.post3
    ~= 2.2.post3
    >= 2.2.post3, == 2.*

    1.4.5a4
    ~= 1.4.5a4
    >= 1.4.5a4, == 1.4.*

The padding rules for release segment comparisons means that the assumed
degree of forward compatibility in a compatible release clause can be
controlled by appending additional zeroes to the version specifier::

    2.2.0
    ~= 2.2.0
    >= 2.2.0, == 2.2.*

    1.4.5.0
    ~= 1.4.5.0
    >= 1.4.5.0, == 1.4.5.*


Version matching
----------------

A version matching clause includes the version matching operator ``==``
and a version identifier.

The specified version identifier must be in the standard format described in
`Version scheme`_, but a trailing ``.*`` is permitted as described below.

By default, the version matching operator is based on a strict equality
comparison: the specified version must be exactly the same as the requested
version. The *only* substitution performed is the zero padding of the
release segment to ensure the release segments are compared with the same
length.

Prefix matching may be requested instead of strict comparison, by appending
a trailing ``.*`` to the version identifier in the version matching clause.
This means that additional trailing segments will be ignored when
determining whether or not a version identifier matches the clause. If the
version includes only a release segment, than trailing components in the
release segment are also ignored.

For example, given the version ``1.1.post1``, the following clauses would
match or not as shown::
    
    == 1.1        # Not equal, so 1.1.post1 does not match clause
    == 1.1.post1  # Equal, so 1.1.post1 matches clause
    == 1.1.*      # Same prefix, so 1.1.post1 matches clause

The use of ``==`` (without at least the wildcard suffix) when defining
dependencies for published distributions is strongly discouraged as it
greatly complicates the deployment of security fixes. The strict version
comparison operator is intended primarily for use when defining
dependencies for repeatable *deployments of applications* while using
a shared distribution index.

Publication tools and index servers SHOULD at least emit a warning when
dependencies are pinned in this fashion and MAY refuse to allow publication
of such overly specific dependencies.


Version exclusion
-----------------

A version exclusion clause includes the version exclusion operator ``!=``
and a version identifier.

The allowed version identifiers and comparison semantics are the same as
those of the `Version matching`_ operator, except that the sense of any
match is inverted.

For example, given the version ``1.1.post1``, the following clauses would
match or not as shown::
    
    != 1.1        # Not equal, so 1.1.post1 matches clause
    != 1.1.post1  # Equal, so 1.1.post1 does not match clause
    != 1.1.*      # Same prefix, so 1.1.post1 does not match clause


Build reference
---------------

A build reference includes the build reference operator ``is`` and
a build label or a build URL.

Publication tools and public index servers SHOULD NOT permit build
references in dependency specifications.

Installation tools SHOULD support the use of build references to identify
dependencies.

Build label matching works solely on strict equality comparisons: the
candidate build label must be exactly the same as the build label in the
version clause for the clause to match the candidate distribution.

For example, a build reference could be used to depend on a ``hashdist``
generated build of ``zlib`` with the ``hashdist`` hash used as a build
label::

    zlib (is d4jwf2sb2g6glprsdqfdpcracwpzujwq)

A build URL is distinguished from a build label by the presence of
``:`` and ``/`` characters in the build reference. As these characters
are not permitted in build labels, they indicate that the reference uses
a build URL.

Some appropriate targets for a build URL are a binary archive, a
source tarball, an sdist archive or a direct reference to a tag or
specific commit in an online version control system. The exact URLs and
targets supported will be installation tool specific.

For example, a local prebuilt wheel file may be referenced directly::

    exampledist (is file:///localbuilds/exampledist-1.0-py33-none-any.whl)

All build URL references SHOULD either specify a local file URL, a secure
transport mechanism (such as ``https``) or else include an expected hash
value in the URL for verification purposes. If an insecure network
transport is specified without any hash information (or with hash
information that the tool doesn't understand), automated tools SHOULD
at least emit a warning and MAY refuse to rely on the URL.

It is RECOMMENDED that only hashes which are unconditionally provided by
the latest version of the standard library's ``hashlib`` module be used
for source archive hashes. At time of writing, that list consists of
``'md5'``, ``'sha1'``, ``'sha224'``, ``'sha256'``, ``'sha384'``, and
``'sha512'``.

For binary or source archive references, an expected hash value may be
specified by including a ``<hash-algorithm>=<expected-hash>`` as part of
the URL fragment.

For version control references, the ``VCS+protocol`` scheme SHOULD be
used to identify both the version control system and the secure transport.

To support version control systems that do not support including commit or
tag references directly in the URL, that information may be appended to the
end of the URL using the ``@<tag>`` notation.

The use of ``is`` when defining dependencies for published distributions
is strongly discouraged as it greatly complicates the deployment of
security fixes. The build label matching operator is intended primarily
for use when defining dependencies for repeatable *deployments of
applications* while using a shared distribution index, as well as to
reference dependencies which are not published through an index server.


Inclusive ordered comparison
----------------------------

An inclusive ordered comparison clause includes a comparison operator and a
version identifier, and will match any version where the comparison is correct
based on the relative position of the candidate version and the specified
version given the consistent ordering defined by the standard
`Version scheme`_.

The inclusive ordered comparison operators are ``<=`` and ``>=``.

As with version matching, the release segment is zero padded as necessary to
ensure the release segments are compared with the same length.


Exclusive ordered comparison
----------------------------

Exclusive ordered comparisons are similar to inclusive ordered comparisons,
except that the comparison operators are ``<`` and ``>`` and the clause
MUST be effectively interpreted as implying the prefix based version
exclusion clause ``!= V.*``.

The exclusive ordered comparison ``> V`` MUST NOT match a post-release
or maintenance release of the given version. Maintenance releases can be
permitted by using the clause ``> V.0``, while both post releases and
maintenance releases can be permitted by using the inclusive ordered
comparison ``>= V.post1``.

The exclusive ordered comparison ``< V`` MUST NOT match a pre-release of
the given version, even if acceptance of pre-releases is enabled as
described in the section below.


Handling of pre-releases
------------------------

Pre-releases of any kind, including developmental releases, are implicitly
excluded from all version specifiers, *unless* a pre-release or developmental
release is explicitly mentioned in one of the clauses. For example, these
specifiers implicitly exclude all pre-releases and development
releases of later versions::

    2.2
    >= 1.0

While these specifiers would include at least some of them::

    2.2.dev0
    2.2, != 2.3b2
    >= 1.0a1
    >= 1.0c1
    >= 1.0, != 1.0b2
    >= 1.0, < 2.0.dev123

By default, dependency resolution tools SHOULD:

* accept already installed pre-releases for all version specifiers
* accept remotely available pre-releases for version specifiers which
  include at least one version clauses that references a pre-release
* exclude all other pre-releases from consideration

Dependency resolution tools SHOULD also allow users to request the
following alternative behaviours:

* accepting pre-releases for all version specifiers
* excluding pre-releases for all version specifiers (reporting an error or
  warning if a pre-release is already installed locally)

Dependency resolution tools MAY also allow the above behaviour to be
controlled on a per-distribution basis.

Post-releases and purely numeric releases receive no special treatment in
version specifiers - they are always included unless explicitly excluded.


Examples
--------

* ``3.1``: version 3.1 or later, but not
   version 4.0 or later. Excludes pre-releases and developmental releases.
* ``3.1.2``: version 3.1.2 or later, but not
   version 3.2.0 or later. Excludes pre-releases and developmental releases.
* ``3.1a1``: version 3.1a1 or later, but not
   version 4.0 or later. Allows pre-releases like 3.2a4 and developmental
   releases like 3.2.dev1.
* ``== 3.1``: specifically version 3.1 (or 3.1.0), excludes all pre-releases,
  post releases, developmental releases and any 3.1.x maintenance releases.
* ``== 3.1.*``: any version that starts with 3.1, excluding pre-releases and
  developmental releases. Equivalent to the ``3.1.0`` compatible release
  clause.
* ``3.1.0, != 3.1.3``: version 3.1.0 or later, but not version 3.1.3 and
  not version 3.2.0 or later. Excludes pre-releases and developmental
  releases.


Updating the versioning specification
=====================================

The versioning specification may be updated with clarifications without
requiring a new PEP or a change to the metadata version.

Actually changing the version comparison semantics still requires a new
versioning scheme and metadata version defined in new PEPs.


Open issues
===========

* The new ``is`` operator seems like a reasonable way to cleanly allow
  installation tools to bring in non-published dependencies, while heavily
  discouraging the practice for published libraries. It also makes
  build labels more useful by allowing them to be used to pin dependencies
  in the integration use case.

  However, it's an early draft of the idea, so feedback is definitely
  welcome.


Summary of differences from \PEP 386
====================================

* Moved the description of version specifiers into the versioning PEP

* added the "build label" concept to better handle projects that wish to
  use a non-compliant versioning scheme internally, especially those based
  on DVCS hashes
  
* added the "compatible release" clause

* added the "build reference" clause

* added the trailing wildcard syntax for prefix based version matching
  and exclusion

* changed the top level sort position of the ``.devN`` suffix

* allowed single value version numbers

* explicit exclusion of leading or trailing whitespace

* explicit criterion for the exclusion of date based versions

* implicitly exclude pre-releases unless explicitly requested

* treat post releases the same way as unqualified releases

* Discuss ordering and dependencies across metadata versions

The rationale for major changes is given in the following sections.


Adding build labels
-------------------

The new build 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.


Changing the version scheme
---------------------------

The key change in the version scheme in this PEP relative to that in
PEP 386 is to sort top level developmental releases like ``X.Y.devN`` ahead
of alpha releases like ``X.Ya1``. This is a far more logical sort order, as
projects already using both development releases and alphas/betas/release
candidates do not want their developmental releases sorted in
between their release candidates and their final releases. There is no
rationale for using ``dev`` releases in that position rather than
merely creating additional release candidates.

The updated sort order also means the sorting of ``dev`` versions is now
consistent between the metadata standard and the pre-existing behaviour
of ``pkg_resources`` (and hence the behaviour of current installation
tools).

Making this change should make it easier for affected existing projects to
migrate to the latest version of the metadata standard.

Another change to the version scheme is to allow single number
versions, similar to those used by non-Python projects like Mozilla
Firefox, Google Chrome and the Fedora Linux distribution. This is actually
expected to be more useful for version specifiers, but it is easier to
allow it for both version specifiers and release numbers, rather than
splitting the two definitions.

The exclusion of leading and trailing whitespace was made explicit after
a couple of projects with version identifiers differing only in a
trailing ``\n`` character were found on PyPI.

The exclusion of major release numbers that look like dates was implied
by the overall text of PEP 386, but not clear in the definition of the
version scheme. This exclusion has been made clear in the definition of
the release component.

`Appendix A` shows detailed results of an analysis of PyPI distribution
version information, as collected on 19th February, 2013. This analysis
compares the behaviour of the explicitly ordered version schemes defined in
this PEP and PEP 386 with the de facto standard defined by the behaviour
of setuptools. These metrics are useful, as the intent of both PEPs is to
follow existing setuptools behaviour as closely as is feasible, while
still throwing exceptions for unorderable versions (rather than trying
to guess an appropriate order as setuptools does).

Overall, the percentage of compatible distributions improves from 97.7%
with PEP 386 to 98.7% with this PEP. While the number of projects affected
in practice was small, some of the affected projects are in widespread use
(such as Pinax and selenium). The surprising ordering discrepancy also
concerned developers and acted as an unnecessary barrier to adoption of
the new metadata standard, even for projects that weren't directly affected.

The data also shows that the pre-release sorting discrepancies are seen
only when analysing *all* versions from PyPI, rather than when analysing
public versions. This is largely due to the fact that PyPI normally reports
only the most recent version for each project (unless maintainers
explicitly configure their project to display additional versions). However,
installers that need to satisfy detailed version constraints often need
to look at all available versions, as they may need to retrieve an older
release.

Even this PEP doesn't completely eliminate the sorting differences relative
to setuptools:

* Sorts differently (after translations): 38 / 28194 (0.13 %)
* Sorts differently (no translations): 2 / 28194 (0.01 %)

The two remaining sort order discrepancies picked up by the analysis are due
to a pair of projects which have PyPI releases ending with a carriage
return, alongside releases with the same version number, only *without* the
trailing carriage return.

The sorting discrepancies after translation relate mainly to differences
in the handling of pre-releases where the standard mechanism is considered
to be an improvement. For example, the existing pkg_resources scheme will
sort "1.1beta1" *after* "1.1b2", whereas the suggested standard translation
for "1.1beta1" is "1.1b1", which sorts *before* "1.1b2". Similarly, the
pkg_resources scheme will sort "-dev-N" pre-releases differently from
"devN" pre-releases when they occur within the same release, while the
scheme in this PEP requires normalizing both representations to ".devN" and
sorting them by the numeric component.


A more opinionated description of the versioning scheme
-------------------------------------------------------

As in PEP 386, the primary focus is on codifying existing practices to make
them more amenable to automation, rather than demanding that existing
projects make non-trivial changes to their workflow. However, the
standard scheme allows significantly more flexibility than is needed
for the vast majority of simple Python packages (which often don't even
need maintenance releases - many users are happy with needing to upgrade to a
new feature release to get bug fixes).

For the benefit of novice developers, and for experienced developers
wishing to better understand the various use cases, the specification
now goes into much greater detail on the components of the defined
version scheme, including examples of how each component may be used
in practice.

The PEP also explicitly guides developers in the direction of
semantic versioning (without requiring it), and discourages the use of
several aspects of the full versioning scheme that have largely been
included in order to cover esoteric corner cases in the practices of
existing projects and in repackaging software for Linux distributions.


Describing version specifiers alongside the versioning scheme
-------------------------------------------------------------

The main reason to even have a standardised version scheme in the first place
is to make it easier to do reliable automated dependency analysis. It makes
more sense to describe the primary use case for version identifiers alongside
their definition.


Changing the interpretation of version specifiers
-------------------------------------------------

The previous interpretation of version specifiers made it very easy to
accidentally download a pre-release version of a dependency. This in
turn made it difficult for developers to publish pre-release versions
of software to the Python Package Index, as even marking the package as
hidden wasn't enough to keep automated tools from downloading it, and also
made it harder for users to obtain the test release manually through the
main PyPI web interface.

The previous interpretation also excluded post-releases from some version
specifiers for no adequately justified reason.

The updated interpretation is intended to make it difficult to accidentally
accept a pre-release version as satisfying a dependency, while allowing
pre-release versions to be explicitly requested when needed.

The "some forward compatibility assumed" default version constraint is
taken directly from the Ruby community's "pessimistic version constraint"
operator [2]_ to allow projects to take a cautious approach to forward
compatibility promises, while still easily setting a minimum required
version for their dependencies. It is made the default behaviour rather
than needing a separate operator in order to explicitly discourage
overspecification of dependencies by library developers. The explicit
comparison operators remain available to cope with dependencies with
unreliable or non-existent backwards compatibility policies, as well
as for legitimate use cases related to deployment of integrated applications.

The optional explicit spelling of the compatible release clause (``~=``) is
inspired by the Ruby (``~>``) and PHP (``~``) equivalents. It is defined
in order to allow easier conversion to the legacy ``pkg_resources`` version
specifier format (which omits the parentheses, but requires a comparison
operator).

Further improvements are also planned to the handling of parallel
installation of multiple versions of the same library, but these will
depend on updates to the installation database definition along with
improved tools for dynamic path manipulation.

The trailing wildcard syntax to request prefix based version matching was
added to make it possible to sensibly define both compatible release clauses
and the desired pre-release handling semantics for ``<`` and ``>`` ordered
comparison clauses.

Build references are added for two purposes. In conjunction with build
labels, they allow hash based references, such as those employed by
`hashdist <http://hashdist.readthedocs.org/en/latest/build_spec.html>`__,
or generated from version control. In conjunction with build URLs, they
allow the new metadata standard to natively support an existing feature of
``pip``, which allows arbitrary URLs like
``file:///localbuilds/exampledist-1.0-py33-none-any.whl``.


References
==========

The initial attempt at a standardised version scheme, along with the
justifications for needing such a standard can be found in PEP 386.

.. [1] Version compatibility analysis script:
   http://hg.python.org/peps/file/default/pep-0426/pepsort.py

.. [2] Pessimistic version constraint
   http://docs.rubygems.org/read/chapter/16


Appendix A
==========

Metadata v2.0 guidelines versus setuptools (note that this analysis was
run when this PEP was still embedded as part of PEP 426)::

    $ ./pepsort.py
    Comparing PEP 426 version sort to setuptools.

    Analysing release versions
      Compatible: 24477 / 28194 (86.82 %)
      Compatible with translation: 247 / 28194 (0.88 %)
      Compatible with filtering: 84 / 28194 (0.30 %)
      No compatible versions: 420 / 28194 (1.49 %)
      Sorts differently (after translations): 0 / 28194 (0.00 %)
      Sorts differently (no translations): 0 / 28194 (0.00 %)
      No applicable versions: 2966 / 28194 (10.52 %)

    Analysing public versions
      Compatible: 25600 / 28194 (90.80 %)
      Compatible with translation: 1505 / 28194 (5.34 %)
      Compatible with filtering: 13 / 28194 (0.05 %)
      No compatible versions: 420 / 28194 (1.49 %)
      Sorts differently (after translations): 0 / 28194 (0.00 %)
      Sorts differently (no translations): 0 / 28194 (0.00 %)
      No applicable versions: 656 / 28194 (2.33 %)

    Analysing all versions
      Compatible: 24239 / 28194 (85.97 %)
      Compatible with translation: 2833 / 28194 (10.05 %)
      Compatible with filtering: 513 / 28194 (1.82 %)
      No compatible versions: 320 / 28194 (1.13 %)
      Sorts differently (after translations): 38 / 28194 (0.13 %)
      Sorts differently (no translations): 2 / 28194 (0.01 %)
      No applicable versions: 249 / 28194 (0.88 %)

Metadata v1.2 guidelines versus setuptools::

    $ ./pepsort.py 386
    Comparing PEP 386 version sort to setuptools.

    Analysing release versions
      Compatible: 24244 / 28194 (85.99 %)
      Compatible with translation: 247 / 28194 (0.88 %)
      Compatible with filtering: 84 / 28194 (0.30 %)
      No compatible versions: 648 / 28194 (2.30 %)
      Sorts differently (after translations): 0 / 28194 (0.00 %)
      Sorts differently (no translations): 0 / 28194 (0.00 %)
      No applicable versions: 2971 / 28194 (10.54 %)

    Analysing public versions
      Compatible: 25371 / 28194 (89.99 %)
      Compatible with translation: 1507 / 28194 (5.35 %)
      Compatible with filtering: 12 / 28194 (0.04 %)
      No compatible versions: 648 / 28194 (2.30 %)
      Sorts differently (after translations): 0 / 28194 (0.00 %)
      Sorts differently (no translations): 0 / 28194 (0.00 %)
      No applicable versions: 656 / 28194 (2.33 %)

    Analysing all versions
      Compatible: 23969 / 28194 (85.01 %)
      Compatible with translation: 2789 / 28194 (9.89 %)
      Compatible with filtering: 530 / 28194 (1.88 %)
      No compatible versions: 547 / 28194 (1.94 %)
      Sorts differently (after translations): 96 / 28194 (0.34 %)
      Sorts differently (no translations): 14 / 28194 (0.05 %)
      No applicable versions: 249 / 28194 (0.88 %)


Copyright
=========

This document has been placed in the public domain.


..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   End: